Kiểm thử phần mềm: Các nguyên tắc cơ bản (Phần 2)

Đây là series tóm tắt từ cuốn sách: FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION của tác giả Dorothy Graham, Erik van Veenendaal, Isabel Evans và Rex Black và một số kinh nghiệm của cá nhân trong quá trình làm việc nhằm cung cấp cho các bạn một cái nhìn tổng quan về kiểm thử phần mềm và các kiến thức cơ bản về kiểm thử, các kỹ thuật dùng trong kiểm thử và các công cụ hỗ trợ.
Để tiếp nối nội dung từ bài viết Kiểm thử phần mềm: Các nguyên tắc cơ bản (Phần 1), trong bài viết lần này, mình sẽ giới thiệu Các quy trình kiểm thử cơ bản và các yếu tố tâm lý học ảnh hưởng đến kiểm thử.

1. Quy trình kiểm thử cơ bản

1.1 Lập kế hoạch và giám sát việc kiểm thử (Test planning and control).

Các bước xây dựng được một kế hoạch kiểm thử.

Xác định phạm vi, các rủi ro và xác định các mục tiêu của việc kiểm thử:
Xem xét những phần mềm, những thành phần, những hệ thống hay sản phẩm khác thuộc phạm
vi kiểm thử.
Những rủi ro kỹ thuật, rủi ro của dự án, rủi ro của sản phẩm và rủi ro trong nghiệp vụ cần được giải quyết.
Mục tiêu của việc kiểm thử là phát hiện ra các lỗi, chứng minh rằng phần mềm đáp ứng được yêu cầu, phù hợp với mục đích hoặc đánh giá được chất lượng cũng như các thuộc tính của phần mềm.
Xác định cách tiếp cận kiểm thử( các công nghệ, item test, phạm vi bao quát, xác định và liên kết giữa các nhóm tham gia kiểm thử, testware):
Xem xét tiến hành kiểm thử như thế nào.
Những công nghệ nào được sử dụng.
Cần kiểm thử những gì.
Phạm vi bao quát như thế nào
Thực thi chính sách kiểm thử và chiến lược kiểm thử:
Trong quá trình lập kế hoạch kiểm thử phải tuân thủ các chính sách, chiến lược hoặc là
phải được sự đồng ý của các bên liên quan.
Xác định yêu cầu về nguồn lực test như con người, môi trường test, PCs…
Lập kế hoạch phân tích việc kiểm thử, nhiệm vụ thiết kế, thực thi việc kiểm thử, thi hành và đánh giá:

Chúng ta cần một kế hoạch của tất cả các hoạt động và nhiệm vụ để có thể theo dõi và đảm
bảo hoàn thành việc kiểm thử đúng thời gian.

Xác định tiêu chuẩn kết thúc (exit criteria):

Cần thiết lập tiêu chuẩn để đảm bảo việc theo dõi các hoạt động kiểm thử và kiểm tra cụ thể được công việc đã hoàn thành ở mức độ như thế nào trước khi kết thúc kiểm thử.

Chúng ta cần kiểm soát và đo lường tiến độ so với kế hoạch, vì vậy kiểm soát việc kiểm thử là một hoạt động liên tục. Kiểm soát kiểm thử có những nhiệm vụ chính sau đây:

Đo lường và phân tích kết quả của việc đánh giá và kiểm thử:
- Để thống kê được có bao nhiêu trường hợp kiểm thử đã thực hiện.
- Theo dõi, kiểm soát số lượng các trường hợp được thông qua, bao nhiêu trường hợp thất bại, số lượng, loại và tầm quan trọng của các lỗi, sai sót trong các báo cáo.
Theo dõi và lập hồ sơ tiến độ, phạm vi kiểm tra và tiêu chuẩn kết thúc:

Điều quan trọng là thông báo cho nhóm dự án biết bao nhiêu kiểm thử đã được thực hiện, kết quả là gì, được đánh giá và kết luận như nào, kết quả có thể nhìn thấy và hữu ích.

Cung cấp thông tin về kiểm thử:

Báo cáo định kỳ và báo cáo đặc biệt cho người quản lý, nhà tài trợ dự án, khách hàng và các bên liên quan chính để giúp họ đưa ra các quyết định về tình hình dự án.

Khởi tạo các hành động khắc phục: ví dụ: thắt chặt các tiêu chuẩn kết thúc đối với các lỗi, sai sót cố định.
Đưa ra quyết định:

Dựa vào các thông tin và báo cáo thu thập được trong quá trình kiểm thử và các rủi ro của dự án mà chúng ta đưa ra quyết định: tiếp tục hay dừng lại, bàn giao phần mềm hoặc giữ lại.

1.2. Phân tích và thiết kế kiểm thử (Test analysis and design).

Phân tích và thiết kế kiểm thử là hoạt động mà tại đó các mục tiêu kiểm thử tổng quát được chuyển đổi thành các điều kiện kiểm thử và thiết kế kiểm thử hữu hình.
Phân tích và thiết kế kiểm thử có các nhiệm vụ chính sau đây.

Xem xét nền tảng kiểm thử( như là phân tích rủi ro của sản phẩm, các yêu cầu, kiến trúc, thiết kế các chi tiết kỹ thuật và giao diện).
Xác định các điều kiện kiểm thử: dựa trên việc phân tích các item test, các chi tiết kỹ thuật, hành vi và cấu trúc phần mềm.
Thiết kế test case
Đánh giá tính khả thi trong việc kiểm thử của yêu cầu cũng như của hệ thống.
-Thiết kế thiết lập môi trường kiểm thử và xác định bất kỳ yêu cầu cơ sở hạ tầng và các công cụ kiểm thử tương ứng.

1.3. Thực hiện và Thực thi kiểm thử (Test implementation and execution).

Trong quá trình thực thi và thực hiện kiểm thử, chúng ta đưa ra các điều kiện kiểm thử trong mỗi trường hợp kiểm thử, phần mềm test (testware) và thiết lập môi trường kiểm thử.
Thực thi và thực hiện kiểm thử có những nhiệm vụ sau đây:

Thực thi(Implementation):
Phát triển và ưu tiên các testcase bằng cách sử dụng các kỹ thuật trong Chương 4 và tạo dữ liệu cho những kiểm thử đó. Viết hướng dẫn để thực hiện các bài test. ở giai đoạn này Chúng ta có thể cần phải tự động hóa một số kiểm thử sử dụng kịch bản test harnesses và automated test (kiểm thử tự động).
Tạo test suites từ các trường hợp kiểm thử để thực hiện kiểm thử hiệu quả.
Thực hiện và xác minh lại môi trường: đảm bảo rằng môi trường đã được thiết lập chính xác, thậm chí có thể chạy kiểm thử trên đó.
Thực hiện (Execution):
Thực thi test suites và trường hợp kiểm thử riêng lẻ theo các phương thức kiểm thử.
Ghi lại kết quả của việc thực hiện kiểm thử: tên, phiên bản của các testware, công cụ kiểm thử.
So sánh kết quả thực tế với kết quả mong đợi.
Viết báo cáo đối với những trường hợp có sự khác biệt giữa kết quả thực tế và kết quả mong đợi.
Xác nhận kiểm thử hoặc tái kiểm thử: Cần thực hiện lại các kiểm thử mà trước đó đã thất bại để xác nhận lại lỗi đấy đã được sửa chữa hay chưa và đảm bảo không phát sinh lỗi khác.

1.4. Đánh giá Tiêu chuẩn kết thúc và báo cáo (Evaluating Exit criteria and reporting).

Dựa trên đánh giá rủi ro của dự án, chúng ta sẽ thiết lập các tiêu chí cho từng hoạt động kiểm thử tương ứng để từ đó có thể xác định được liệu kiểm thử đã đủ hay chưa. Những tiêu chí này khác nhau tùy từng dự án và được gọi tiêu chí kết thúc kiểm thử (exit criteria). Các tiêu chí này bao gồm:

Số lượng test case tối đa được thực thi Passed
Tỷ lệ lỗi giảm xuống dưới mức nhất định
Khi đến deadline.

Việc đánh giá Exit criteria gồm các nhiệm vụ chủ yếu sau:

Kiểm tra test logs với các tiêu chí kết thúc được chỉ định trong quá trình lập kế hoạch:

Xem xét những bằng chứng mà chúng ta đã kiểm thử, những lỗi nào đã được đưa ra, lỗi đã sửa, xác nhận kiểm tra hoặc đang giải quyết.

Từ đó, đánh giá xem liệu có cần phải test thêm hay điều chỉnh các tiêu chí kết thúc kiểm thử trong kế hoạch:
Chúng ta cần phải chạy thêm nhiều thử nghiệm nếu không chạy hết tất cả các test như đã thiết kế hoặc không đạt được bản báo cáo tình hình như dự kiến hoặc là rủi ro trong dự án tăng lên.
Viết báo cáo tóm tắt hoạt động kiểm thử cũng như kết quả kiểm thử cho các bên liên quan.

1.5. Các hoạt động kết thúc kiểm thử (Test closure activities)

Các hoạt động kiểm thử thường chỉ được kết thức khi các phần mềm được bàn giao cho khách hàng. Ngoài ra, hoạt đông kiểm thử có thể kết thức trong các trường hợp sau:

khi đã thu thập đầy đủ thông tin cần thiết cho việc kiểm thử.
khi dự án bị hủy bỏ.
Khi các mục tiêu chính đã hoàn thành.
Khi việc bảo trì hoặc cập nhật đã hoàn thành.

Các hoạt động kết thúc kiểm thử bao gồm những nhiệm vụ chính sau:

Kiểm tra khách hàng được nhận sản phẩm theo dự kiến từ đầu và đảm bảo rằng tất cả sự cố đã được giải quyết.
Hoàn thiện và lưu trữ phần mềm testware, chẳng hạn như các kịch bản, môi trường thử nghiệm và bất kỳ cơ sở hạ tầng thử nghiệm nào khác để sử dụng lại sau này.
Bàn giao testware cho tổ chức bảo trì sẽ hỗ trợ phần mềm và thực hiện bất kỳ sửa lỗi hoặc thay đổi bảo trì nào, để sử dụng trong kiểm tra xác nhận và kiểm tra hồi quy.
Đánh giá cách kiểm thử và đưa ra bài học cho lần phát hành và các dự án khác trong tương lai.

5. Các yếu tố tâm lý học trong kiểm thử

Tính độc lập -Independence: Sự phân chia trách nhiệm khuyến khích hoàn thành mục tiêu kiểm thử.
Đoán lỗi - Error guessing: Một kỹ thuật thiết kế kiểm thử mà các kinh nghiệm của tester được sử dụng để dự đoán những lỗi có thể xuất hiện trong thành phần hoặc hệ thống trong khi test.
Các developer có thể kiểm tra và tìm thấy lỗi trong code của họ nhưng ở một mức độ nhất định của tính độc lập thì tester làm việc hiệu quả hơn trong việc tìm kiếm các lỗi (error) và các thất bại(failed).
Một số cấp độ của tính độc lập được định nghĩa từ thấp đến cao như dưới đây:
- Các kiểm thử được thiết kế bởi những người viết phần mềm.
- Các kiểm thử được thiết kế bởi người khác (ví dụ như đội phát triển).
- Các kiểm thử được thiết kế bởi người từ một nhóm tổ chức khác nhau (một đội kiểm thử độc lập) hoặc chuyên gia kiểm thử.
- Các kiểm thử được thiết kế bởi người từ một tổ chức hoặc công ty khác nhau.
Để tìm thấy lỗi trong phần mềm đòi hỏi tính tỉ mỉ, chuyên nghiệp, chú ý đến từng chi tiết, giao tiếp tốt với đội phát triển, đoán lỗi dựa trên kinh nghiệm.
Những lỗi(error) và khuyết thiếu(defects) phải được truyền đạt, mô tả rõ ràng, tránh mâu thuẫn giữa tester và các nhà phân tích, người thiết kế và các nhà phát triển.
Test leader và tester cần có kỹ năng giao tiếp tốt để truyền đạt thông tin thực tế về lỗi, tiến độ và rủi ro. Lỗi được tìm thấy và sửa chữa trong thời gian kiểm thử sẽ tiết kiệm thời gian , tiền bạc và giảm thiểu rủi ro.

Một số cách để cải thiện giao tiếp và các mối quan hệ giữa tester và những người khác:

Bắt đầu với sự hợp tác thay vì trận chiến.
Truyền đạt phát hiện lỗi trên sản phẩm một cách trung lập, không chỉ trích người đã tạo ra lỗi.
Cố gắng hiểu người khác cảm thấy thế nào và lý do tại sao họ phản ứng như vậy.
Xác nhận với người kia đã hiểu những gì bạn nói và ngược lại.

Mình vừa giới thiệu với các bạn về quy trình kiểm thử cơ bản của kiểm thử và các yếu tố tâm lý học ảnh hưởng đến kiểm thử. Sang phần sau chúng ta sẽ đi tìm hiểu các mô hình phát triển phần mềm.
Link bài viết tiếp theo Kiểm thử phần mềm: Các mô hình phát triển phần mềm.