So với ISTQB bản 3.1 thì bản ISTQB 4.0 đã thay đổi tên gọi quy tắc test số 5 từ Beware of the pesticide paradox sang Tests wear out sát nghĩa hơn so với bản 3.1
Mình cùng tìm hiểu nội dung và ý nghĩa của từng nguyên tắc test theo Syllabus ISTQB 4.0 nhé
1. Kiểm thử chỉ ra các lỗi gặp phải, không chứng tỏ vắng mặt của lỗi: Kiểm thử có thể chỉ ra các lỗi có trong đối tượng kiểm thử hay tính năng được kiểm thử, nhưng nó không chứng minh rằng tính năng đó không có lỗi (Buxton 1970). Việc kiểm thử giảm xác suất có lỗi chưa được phát hiện trong tính năng, nhưng ngay cả khi không tìm thấy lỗi nào thì việc kiểm thử không thể chứng minh đối tượng kiểm thử là hoàn toàn chính xác hoặc hoàn toàn hết lỗi
2. Kiểm tra toàn bộ là không thể: Kiểm tra tất cả mọi thứ là không thể trừ những trường hợp cực kỳ đơn giản (Manna 1978). Thay vì cố gắng kiểm thử toàn bộ thì nên áp dụng các kỹ thuật kiểm thử (chương 4) hoặc tập trung vào việc kiểm thử theo mức độ ưu tiên trường hợp kiểm thử (mục 5.1.5) và kiểm thử dựa trên rủi ro (mục 5.2)
3. Kiểm thử sớm tiết kiệm thời gian và chi phí: Những lỗi được xử lý sớm trong quy trình sẽ không gây ra các lỗi sau đó trong các sản phẩm công việc tiếp theo. Chi phí chất lượng sẽ được giảm bớt vì ít sự cố hơn xảy ra trong giai đoạn sau của vòng đời phát triển phần mềm (Boehm 1981). Để tìm lỗi sớm thì các hoạt động kiểm thử như kiểm thử tĩnh (xem chương 3) và kiểm thử động (xem chương 4) nên được bắt đầu càng sớm càng tốt
4. Lỗi tập trung thành cụm: Một số lượng nhỏ các tính năng của hệ thống thường chứa hầu hết các lỗi được phát hiện hoặc cho hầu hết các sự cố vận hành (Enders 1975). Hiện tượng này là minh họa của nguyên lý Pareto. Dự đoán lỗi theo cụm và cụm lỗi thực tế quan sát được trong quá trình kiểm thử hoặc vận hành là một đầu vào quan trọng cho kiểm thử dựa trên rủi ro (xem mục 5.2)
5. Kiểm thử bị hao mòn đi: Nếu các kịch bản kiểm thử giống nhau được lặp lại nhiều lần thì chúng sẽ bị kém hiệu quả dần trong việc phát hiện các lỗi mới (Beizer 1990). Để khắc phục việc này này, các kịch bản kiểm thử đang có và dữ liệu kiểm thử cần được thay đổi, và các kịch bản kiểm thử mới có thể cần được viết bổ sung thêm. Tuy nhiên, trong một số trường hợp, lặp lại cùng các kịch bản kiểm thử có thể mang lại kết quả tích tốt, ví dụ trong kiểm thử regression test với automation (mục 2.2.3)
6. Kiểm thử phụ thuộc vào từng hoàn cảnh: Không có một phương pháp kiểm thử duy nhất áp dụng chung cho tất cả mọi trường hợp hay mọi tổ chức hoặc dự án. Kiểm thử được thực hiện khác nhau trong các hoàn cảnh khác nhau (Kaner 2011)
7. Sai lầm về sự vắng mặt của lỗi: Đây là một sai lầm (tức là một hiểu lầm) khi kỳ vọng rằng việc verification (test phần mềm so với yêu cầu đặc tả/ user story) sẽ đảm bảo thành công của hệ thống. Kiểm tra tất cả các yêu cầu được yêu cầu và fix tất cả các lỗi tìm thấy cũng vẫn có thể tạo ra một hệ thống không đáp ứng được nhu cầu và mong đợi của người dùng, không đạt được mục đích kinh doanh của khách hàng và kém hơn so với các hệ thống cạnh tranh khác.
Ngoài việc verification(test phần mềm so với yêu cầu đặc tả/ user story), việc validation (xác nhận cái khách hàng cần, test dưới góc độ end user) cũng cần được thực hiện để đảm bảo cung cấp đúng cái khách hàng cần
Nội dung gốc:
1. Testing shows the presence, not the absence of defects. Testing can show that defects are present in the test object, but cannot prove that there are no defects (Buxton 1970). Testing reduces the probability of defects remaining undiscovered in the test object, but even if no defects are found, testing cannot prove test object correctness.
2. Exhaustive testing is impossible. Testing everything is not feasible except in trivial cases (Manna 1978). Rather than attempting to test exhaustively, test techniques (see chapter 4), test case prioritization (see section 5.1.5), and risk-based testing (see section 5.2), should be used to focus test efforts.
3. Early testing saves time and money. Defects that are removed early in the process will not cause subsequent defects in derived work products. The cost of quality will be reduced since fewer failures will occur later in the SDLC (Boehm 1981). To find defects early, both static testing (see chapter 3) and dynamic testing (see chapter 4) should be started as early as possible.
4. Defects cluster together. A small number of system components usually contain most of the defects discovered or are responsible for most of the operational failures (Enders 1975). This phenomenon is an illustration of the Pareto principle. Predicted defect clusters, and actual defect clusters observed during testing or in operation, are an important input for risk-based testing (see section 5.2).
5. Tests wear out. If the same tests are repeated many times, they become increasingly ineffective in detecting new defects (Beizer 1990). To overcome this effect, existing tests and test data may need to be modified, and new tests may need to be written. However, in some cases, repeating the same tests can have a beneficial outcome, e.g., in automated regression testing (see section 2.2.3).
6. Testing is context dependent. There is no single universally applicable approach to testing. Testing is done differently in different contexts (Kaner 2011).
7. Absence-of-defects fallacy. It is a fallacy (i.e., a misconception) to expect that software verification will ensure the success of a system. Thoroughly testing all the specified requirements and fixing all the defects found could still produce a system that does not fulfill the users’ needs and expectations, that does not help in achieving the customer’s business goals, and that is inferior compared to other competing systems. In addition to verification, validation should also be carried out (Boehm 1981).
