Kiểm thử không chỉ là thực thi test case và tìm bug. Theo ISTQB, có 7 nguyên lý kiểm thử giúp chúng ta hiểu đúng bản chất, giới hạn và cách tổ chức hoạt động testing hiệu quả.

1. Kiểm thử chỉ chứng minh sự hiện diện của lỗi (defect always exists)

Testing có thể cho thấy phần mềm đang có defect, nhưng không thể chứng minh rằng sản phẩm hoàn toàn không còn defect. Không tìm thấy bug chỉ có nghĩa là chưa tìm thấy bug trong phạm vi và điều kiện đã kiểm thử.

Ví dụ: 500 test case đều pass không đồng nghĩa hệ thống chắc chắn không còn lỗi.

Tips: Hãy luôn dùng nguyên lý này để bảo vệ mình, nhất là khi bạn tranh luận với “sếp” luôn đổi lỗi cho tester 🥲

2. Kiểm thử toàn bộ là bất khả thi (exhausive testing is imposible)

Không thể kiểm tra mọi tổ hợp dữ liệu, điều kiện và luồng sử dụng, trừ những hệ thống cực kỳ đơn giản. Vì vậy, tester cần ưu tiên dựa trên rủi ro, kỹ thuật kiểm thử và mức độ quan trọng của chức năng. Không thể “vét cạn” mọi trường hợp, vì thời gian và effort là hữu hạn.

Ví dụ: Một ô ngày tháng có vô số giá trị và cách nhập; chúng ta chọn các phân vùng và giá trị biên thay vì thử tất cả.

3. Kiểm thử sớm giúp tiết kiệm thời gian và chi phí (early testing)

Hoạt động testing nên bắt đầu càng sớm càng tốt trong vòng đời phát triển. Phát hiện vấn đề ngay từ requirement hoặc thiết kế thường rẻ hơn nhiều so với sửa lỗi sau khi đã release.

Ví dụ: Review user story phát hiện thiếu quy tắc hoàn tiền trước khi developer viết code. Chứ nếu để ông dev code xong hết rồi mới phát hiện ra bug thì đã quá muộn, việc fix sẽ rất tốn chi phí.

4. Lỗi thường tập trung thành cụm (bug cluster)

Một số ít module thường chứa phần lớn defect hoặc gây ra phần lớn failure. Tester nên dùng dữ liệu lỗi trước đây để tập trung thêm vào những khu vực phức tạp, thay đổi nhiều hoặc từng có nhiều bug.

Ví dụ: Module thanh toán liên tục phát sinh lỗi sau mỗi lần cập nhật nên cần regression test sâu hơn. Các module khác giảm bớt test case đi cũng được. Như vậy sẽ tăng hiệu quả

5. Test sẽ mất dần hiệu quả (test wears out)

Nếu lặp lại mãi cùng một bộ test, sau một thời gian chúng sẽ ít tìm thấy defect mới. Test case và test data cần được rà soát, cập nhật và bổ sung thường xuyên.

Ví dụ: Ngoài chạy regression suite cũ, tester bổ sung dữ liệu bất thường và exploratory testing cho các thay đổi mới. Nên luôn cập nhật và maintain bộ test. Tránh đểu nó out-dated.

Note: Ngày xưa nguyên lý này gọi là “Hiệu ứng thuốc trừ sâu”, để liên tưởng tới việc sâu bọ kháng lại thuốc trừ sâu trong 1 thời gian dài sử dụng 😁

6. Kiểm thử phụ thuộc vào ngữ cảnh (context-dependence)

Không có một cách testing phù hợp cho mọi sản phẩm. Chiến lược, mức độ nghiêm ngặt và kỹ thuật kiểm thử phải phụ thuộc vào domain, rủi ro và mục tiêu của hệ thống.

Ví dụ: Phần mềm y tế cần yêu cầu an toàn và bằng chứng kiểm thử nghiêm ngặt hơn một website giới thiệu nội bộ. Test game thì sẽ phải test khác với test 1 hệ thống ngân hàng…

7. Không có lỗi không có nghĩa là sản phẩm thành công

Ngay cả khi đã sửa gần hết defect, sản phẩm vẫn thất bại nếu không đáp ứng nhu cầu người dùng hoặc không hỗ trợ mục tiêu kinh doanh. Đây được gọi là ngụy biện không có lỗi (absence-of-defects fallacy).

Ví dụ: Ứng dụng chạy đúng đặc tả nhưng quy trình đặt hàng quá phức tạp khiến khách hàng không muốn sử dụng. Sản phẩm vẫn fail sau khi đến tay khách hàng!

Kết luận

Bảy nguyên lý trên nhắc tester rằng testing luôn có giới hạn. Muốn kiểm thử hiệu quả, chúng ta cần bắt đầu sớm, ưu tiên theo rủi ro, thay đổi cách kiểm thử và luôn đặt chất lượng sản phẩm trong đúng bối cảnh sử dụng 👌