14 Nguyên Tắc Trong Kiểm Thử Phần Mềm

1. Testing shows the presence of defects, not their absence
2. Exhaustive testing is impossible
3. Early testing saves time and money
4. Defects cluster together
5. Beware the Pesticide Paradox
6. Testing is context-dependent
7. Absence of errors is a fallacy
8. Business first
9. Bottlenecks out
10. Always learn and improve
11. Lead about the quality culture
12. The customer is King
13. Data trumps intuition
14. Everyone can test

1. Testing shows presence of defects, not their absence

Kiểm thử chỉ ra sự hiện diện của lỗi chứ không phải sự vắng mặt của chúng. Kiểm thử giúp giảm xác xuất của lỗi chưa được tìm thấy trong phần mềm. Tuy vậy kiểm thử không phải là bằng chứng cho một sản phẩm không còn lỗi.

2. Exhaustive testing is impossible

Kiểm thử vét cạn là không thể. Thông thường không thể kiểm tra hết tất cả yếu tố đầu vào, đầu ra và điều kiện tiên quyết. Thay vào đó, người kiểm thử nên ưu tiên dựa trên mức độ rủi ro đối với sản phẩm.

3. Early testing saves time and money

Kiểm thử càng sớm càng tốt. Người kiểm thử không phải đợi đến khi sản phẩm release mới tiến hành kiểm thử. Lỗi được phát hiện sớm trong vòng đời phát triển sản phẩm sẽ dễ sửa và tiết kiệm được tiền bạc.

4. Defect cluster together

Cụm lỗi. Điều này có nghĩa là lỗi thường hay xuất hiện tập trung. Hầu hết các lỗi trong phần mềm đều theo nguyên tắc Pareto: có nghĩa là 80% lỗi thường xuất phát từ 20% mô-đun (model). Mặc dù sẽ có những ngoại lệ, nhưng đây là một quy tắc hữu ích để kiểm tra sự tập trung của lỗi.

5. Beware the Pesticide Paradox

Cẩn thận nghịch lý thuốc trừ sâu. Điều này vay mượn từ ý tưởng trong nông nghiệp rằng sử dụng lặp đi lặp lại cùng một loại thuốc trừ sâu sẽ dẫn đến giảm hiệu quả của thuốc. Trong thế giới phần mềm, điều này có nghĩa là các trường hợp kiểm thử thông thường cuối cùng sẽ ngừng tìm ra các lỗi mới. Do đó cần phải xem xét và sửa đổi các trường hợp kiểm thử thường xuyên.

6. Testing is context dependent

Kiểm thử phụ thuộc vào ngữ cảnh. Mô hình kiểm thử lặp đi lặp lại sẽ không còn đúng với tất cả các trường hợp. Ví dụ, kiểm thử cho trang thương mại điện tử với lượng truy cập cao sẽ khác với ứng dụng dành cho nhân viên nội bộ của công ty.

7. Absence of errors fallacy

Không có lỗi là một sai lầm. Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm không có lỗi và sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi có thể do việc kiểm thử nhằm vào kiểm tra tính năng theo yêu cầu thay vì tìm kiếm lỗi mới.

8. Business first

Ưu tiên của chúng ta là cải thiện hoạt động kinh doanh.

9. Bottlenecks out

Chúng ta tăng tốc hoạt động của nhóm và sử dụng các mô hình như Tư duy tinh gọn và Lý thuyết về các ràng buộc để giúp xác định, ưu tiên và giảm thiểu tắc nghẽn từ hệ thống.

10. Always learn and improve

Chúng ta là lực lượng cải tiến liên tục, giúp đội nhóm thích ứng và tối ưu hóa để thành công, thay vì cung cấp một dịch vụ an toàn nhưng không mang lại giá trị cao.

11. Lead about the quality culture

Chúng ta quan tâm sâu sắc đến văn hóa chất lượng của nhóm mình, đồng thời chúng ta huấn luyện, lãnh đạo và nuôi dưỡng nhóm hướng tới một nền văn hóa chất lượng trưởng thành hơn.

12. The customer is King

Chúng ta tin rằng khách hàng là người duy nhất có khả năng đánh giá và đánh giá chất lượng sản phẩm của chúng tôi.

13. Data trumps intuition

Chúng ta sử dụng rộng rãi dữ liệu để hiểu sâu về cách sử dụng của khách hàng, sau đó thu hẹp khoảng cách giữa các giả thuyết về sản phẩm và tác động kinh doanh.

14. Everyone can test

Chúng ta mở rộng khả năng thử nghiệm và bí quyết trong toàn nhóm; hiểu rằng điều này có thể làm giảm (hoặc loại bỏ) nhu cầu có chuyên gia kiểm tra tận tâm.

Happy Testing!