Người kiểm thử mới cần làm gì?
Tôi nhận được một email từ một sinh viên: “Em sẽ tốt nghiệp trong Khoa học máy tính năm nay và tìm việc làm. Có thể là em sẽ bắt đầu làm người kiểm thử phần mềm. Có khác biệt giữa trường học và công nghiệp liên quan tới kiểm thử phần mềm không? Kiểm thử thực tế được thực hiện trong công ty phần mềm thế nào? Thầy có ‘lời khuyên thực hành’ nào không?"
Đáp: Phần lớn sinh viên tính toán bắt đầu nghề nghiệp của họ là người kiểm thử phần mềm nơi họ học về dự án phần mềm trước khi chuyển sang vị trí khác. Sau đây là một số lời khuyên, tôi dùng vòng đời thác đổ vì nó vẫn được dùng trong hầu hết các công ti, tôi sẽ thảo luận về kiểm thử agile trong bài viết khác:
Giả sử rằng bạn bắt đầu một dự án mới. Mọi dự án đều bắt đầu bằng cuộc họp "khởi động". Trong cuộc họp này người quản lí dự án sẽ giải thích về khách hàng và người dùng của dự án (nội bộ hay bên ngoài), phạm vi dự án, thời gian, lịch biểu và khi nào nó phải được chuyển giao. Người quản lí sẽ phân công các vai trò, trách nhiệm và thẩm quyền cho từng thành viên. Chẳng hạn người quản lí dự án, lãnh đạo kĩ thuật, đảm bảo chất lượng, lãnh đạo tổ, người phát triển, người kiểm thử v.v.
Phần lớn các dự án bắt đầu từ đặc tả yêu cầu phần mềm Software Requirement Specification (SRS) nơi kế hoạch dự án được phát triển. Điều đầu tiên người kiểm thử phải làm là kiểm điểm SRS và tạo ra bản kế hoạch kiểm thử phần mềm. Bản kế hoạch kiểm thử có thể được tách rời hay được đưa vào trong bản kế hoạch dự án. Bản kế hoạch kiểm thử bao quát mọi hoạt động kiểm thử: mục tiêu, phân công kiểm thử (ai sẽ kiểm thử mô đun nào), loại kiểm thử nào được tiến hành theo lịch (như, tích hợp, an ninh, rà lại v.v..), số các chức năng được kiểm thử, tiêu chí rủi ro, lịch biểu kiểm thử, phương pháp kiểm thử, công cụ kiểm thử, và môi trường kiểm thử (hỗ trợ nền). Bản kế hoạch kiểm thử sẽ được người quản lí dự án kiểm điểm để chấp thuận. Điển hình, người lãnh đạo kiểm thử sẽ viết ra bản kế hoạch kiểm thử nhưng mọi người kiểm thử đều có thể tham gia và đóng góp vào bản kế hoạch này. Cho dù bạn là người kiểm thử mới, bạn nên làm quen với bản kế hoạch kiểm thử bởi vì đây là tài liệu đầu tiên bạn phải hiểu rõ để làm việc của mình.
Dự án sẽ chuyển sang pha kiến trúc (mức cao) và pha thiết kế (mức chi tiết) nơi công việc dự án được chia thành các mô đun khác nhau hay các nhiệm vụ nhỏ hơn và được phân công cho người phát triển viết mã. Người kiểm thử phải tham gia vào cả kiểm điểm kiến trúc và thiết kế để hiểu cách công việc dự án được chia ra, cách từng chức năng được chia thành các mô đun nhỏ hơn, cách từng mô đun được chia thành các nhiệm vụ nhỏ hơn (nếu cần). Bằng việc hiểu các công việc dự án này, người kiểm thử có thể tạo ra kịch bản kiểm thử và trường hợp kiểm thử tương ứng với từng mô đun hay nhiệm vụ được phân công. Những trường hợp kiểm thử này sẽ được tổ hợp lại về sau trong các trường hợp kiểm thử chức năng tương ứng với SRS.
Nhiều người kiểm thử không thích tham gia vào kiểm điểm, nhưng đợi cho tới khi việc viết mã được hoàn thành rồi bắt đầu viết trường hợp kiểm thử. Đó là sai lầm lớn. Nếu người kiểm thử KHÔNG tham gia vào kiểm điểm, họ sẽ KHÔNG hiểu dự án đủ rõ để viết trường hợp kiểm thử tốt. Nếu họ bỏ lỡ cái gì, điều đó sẽ tạo ra nhiều vấn đề hơn về sau trong hoạt động kiểm nghiệm. Điều bản chất cho mọi thành viên dự án, kể cả người kiểm thử và người phát triển, là tham gia vào kiểm điểm dự án bởi vì đây là lúc họ thực sự học về dự án. Nhiều người kiểm thử mới bảo tôi rằng họ KHÔNG thích kiểm điểm vì chúng có quá nhiều chi tiết kĩ thuật tới mức họ không hiểu, và họ không muốn ngồi yên tĩnh và "có vẻ ngu". Câu trả lời của tôi là: “Không ai chú ý tới bạn vì bạn chỉ mới bắt đầu việc mới của bạn. Tuy nhiên, mọi người sẽ hỏi bạn các câu hỏi và có mong đợi sau khi bạn đã làm ở việc này trong vài tháng. Cho nên điều quan trọng với bạn, như người kiểm thử mới, là học cái gì đó nhanh chóng, nếu bạn KHÔNG muốn "có vẻ ngu" sáu tháng sau khi làm việc ở đó mà vẫn không thể trả lời được cái gì.
Khi người phát triển hoàn thành từng mô đun riêng của họ, họ sẽ kiểm thử mã riêng của họ (kiểm thử đơn vị) trước khi phân công cho người kiểm thử về trắc nghiệm độc lập. Người kiểm thử sẽ bắt đầu kiểm thử mô đun bằng việc thực hiện trường hợp kiểm thử riêng của họ để chắc chắn rằng các mô đun này làm việc. Nếu chúng không làm việc, mô đun được gửi trả lại cho người phát triển để sửa chúng. Kiểm thử mô đun là không thể vét hết được, chỉ kiểm tra liệu mô đun có chạy tương ứng và không đi vào chi tiết. Vào lúc này, bất kì lỗi nào được tìm thấy đều phải được ghi lại trong công cụ theo dõi vết để trắc nghiệm về sau. Điều quan trong là đảm bảo rằng mọi lỗi đã được nhận diện đều được sửa trước khi đưa ra cho khách hàng. Sau khi người phát triển đã sửa lỗi, người kiểm thử phải thực hiện kiểm thử của họ lần nữa để trắc nghiệm rằng nó đã qua được và lỗi sẽ được đánh dấu là "đóng". Bằng không, nó vẫn còn "mở" nghĩa là nó còn chưa được chữa. Loại kiểm thử rà lại này là rất quan trọng để tìm lỗi sau khi thay đổi hay sửa chữa đã được thực hiện. Nó được thiết kế để giả định rằng thay đổi hay sửa chữa không tạo ra lỗi mới. Mọi thông tin về lỗi đều phải được làm tài liệu trong báo cáo trạng thái lỗi (báo cáo lỗi) và gửi cho người quản lí dự án trên cơ sở hàng tuần (Đôi khi hàng ngày nếu đó là qui trình dựng hàng ngày).
Có vài kiểu kiểm thử, tuỳ theo yêu cầu của dự án và khách hàng. Thông thường, vài mô đun được tổ hợp rồi người kiểm thử sẽ thực hiện kiểm thử tích hợp hay kiểm thử tích hợp mô đun. Nếu vài mô đun được tổ hợp thành chức năng thì người kiểm thử sẽ thực hiện kiểm thử chức năng. Có kiểm thử phụ đi vào chi tiết hơn trên các phần cứng khác nhau, phiên bản hệ điều hành, các nền, hay các trình duyệt khác nhau v.v. Tất cả những kiểm thử này phải được lập kế hoạch và làm tài liệu trong bản kế hoạch kiểm thử dựa trên SRS.
Cuối cùng nếu mọi kiểm thử đều qua, toàn bộ sản phẩm phần mềm được trải qua kiểm thử hệ thống trong môi trường kiểm thử tương tự như môi trường của người dùng. (Thỉnh thoảng nó có thể được thực hiện trong "môi trường" người dùng thực tại, nếu dự án là nội bộ hay phát triển tại chỗ). Nếu sản phẩm qua được mọi trường hợp kiểm thử, người kiểm thử sẽ viết báo cáo kiểm thử cuối cùng và người quản lí dự án sẽ ra quyết định đưa ra sản phẩm cho khách hàng.
Lời khuyên của tôi là: “Nếu bạn bắt đầu làm việc như người kiểm thử mới, bạn phải học về vòng đời dự án phần mềm được dùng trong dự án. Bạn phải kiểm điểm đặc tả yêu cầu phần mềm (SRS) để hiểu dự án (tôi biết rằng việc đó là chán, một số SRS sẽ làm cho bạn buồn ngủ nhưng nhớ rằng bạn đang học làm việc và đây là việc thực). Bạn phải hiểu mục đích và mục tiêu dự án, cũng như lịch biểu và ngày mục tiêu để đưa ra. Là người kiểm thử mới, bạn phải biết chi tiết kế hoạch kiểm thử để cho bạn hiểu mục tiêu dự án, phương pháp kiểm thử, tính năng hay chức năng được kiểm thử, hay KHÔNG được kiểm thử. Rủi ro kiểm thử, lịch biểu kiểm thử, môi trường hỗ trợ và nền được dùng để kiểm thử và mọi chi tiết kĩ thuật về kiểm thử phần mềm. Điều rất quan trọng cho bạn là tham gia vào mọi cuộc kiểm điểm dự án. ĐỪNG đợi cho tới khi pha viết mã xong rồi mới bắt đầu làm việc trên các trường hợp kiểm thử của mình. Bạn phải bắt đầu viết các trường hợp kiểm thử vào cùng lúc người phát triển bắt đầu thiết kế của họ rồi thêm nhiều chi tiết hơn khi nhiều thông tin hơn là sẵn có. Bạn phải học cách dùng công cụ theo dõi lỗi (công cụ dõi lỗi) và có khả năng viết báo cáo tình trạng lỗi (báo cáo lỗi).
Điều đó có thể dường như là nhiều nhưng có nhiều điều hơn mà bạn sẽ phải học trong công nghiệp phần mềm để thăng tiến nghề nghiệp của bạn. Xin giữ thái độ tích cực và nhớ rằng bạn vẫn học vì nghề nghiệp chuyên môn của bạn chỉ mới được bắt đầu.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Lời khuyên cho sinh viên
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
