Nguyên tắc kiễm thử

Tất cả các chiến lược kiễm thử phần mềm đều dựa trên một vài nguyên tắc kiễm thử sau đây:

1. Tất cả các kiễm thửđều có thể lần theo vết đến yêu cầu ban đầu của phần mềm. Mối quan hệ này cho chúng ta biết được tính đúng đắn của nội dung đang kiễm thử đối với yêu cầu ban đầu – được dùng làm tiêu chuẩn đánh giá. Nhưng làm sao để biết các yêu cầu ban đầu là hợp lý ? Theo quan điểm hệ thống, đó là (1) yêu cầu phải hướng đến việc tạo ra (cộng thêm) giá trị thiết thực cho hệ thống lớn hơn (dây chuyền tạo ra giá trị của tổ chức), (2) yêu cầu được công nhận là khả thi, (3) hệ thống mới phải tương thích hoàn toàn với những gì được giữ lại (không thay đổi) của hệ thống củ (tương tự như khi chúng ta muốn thay một cánh cửa, thì chiếc cửa mới phải lắp vừa với khung cửa củ, trừ khi chúng ta muốn bỏ luôn khung cửa củ), và (4) các yêu cầu phải qua kiểm chứng với thực tế.

2. Các hoạt động kiễm thử được hoạch định và tiến hành càng sớm càng tốt. Nhìn một cách tổng quát thì quá trình phát triển phần mềm là từ tổng quát đến chi tiết; càng về sau thì chi phí sửa sai cho các mức tổng quát bên trên càng lớn do phải sửa lại nhiều mô-đun liên quan. Do đó, làm đúng ngay từ đầu là cách tốt nhất để giảm chi phí làm lại (“rework”).

3. Kiễm thử bắt đầu từ nhỏ (đơn giản, dể hiểu) và hướng đến lớn (phức tạp). Vì kiễm thử là phải xác định đúng/sai, do đó người kiểm thử phải hiểu rõ một nội dung nào đó trước khi kiễm thử nó. Cách tiếp cận ít sai sót nhất là bắt đầu từ đơn giản đến phức tạp để phù hợp với sự hiểu biết ngày càng nhiều của người thực hiện.

4. Không kiễm thử hết tất cả mọi thứ, mà phải có chọn lọc. Các mẫu thử được chọn sao cho việc kiễm thử không bị dư thừa, ví dụ chỉ kiểm thử cho các trường hợp đại diện; không kiễm thử lại những trường hợp tương tự. Việc này làm cho chất lượng kiễm thử tốt hơn nhờ tập trung nguồn lực vào những vấn đề chính.

5. Kiễm thử cần được tiến hành một cách khách quan (người kiễm thử không phải là tác giả của nội dung bị kiễm thử).