ISTQB Foundation – 7 nguyên lý kiểm thử
- March 2, 2021
- Posted by: codestar
- Category: Technology
Trong kiểm thử phần mềm, có 7 nguyên lý vô cùng quan trọng. Hãy cùng tìm hiểu xem 7 nguyên lý này là gì nhé!
1. Tesing có thể show lỗi nhưng không thể đảm bảo phần mềm không còn lỗi
Testing giảm xác suất lỗi còn lại trong phần mềm, tuy nhiên kể cả trường hợp không có lỗi nào được tìm thấy, điều đó cũng không là thể mình chứng cho sự đúng đắn của phần mềm.
2. Test tất cả là không thể
Việc test tất cả(kết hợp tất cả các điều kiện, các input) là không khả thi, ngoại trừ trong 1 số trường hợp nhỏ.
Thay vì test tất cả, thì chúng ta nên tập trung vào phân tích rủi ro, các kỹ thuật test và độ ưu tiên
3. Test càng sớm càng tốt
Để phát hiện lỗi sớm, các hoạt động test tinhgx và test động cần phải được thực hiện càng sớm càng tốt trong vòng đời phát triển của phần mềm.
Test sớm giúp giảm or loại bỏ được phần chi phí cần bỏ ra cho việc thay đổi.
4. Cụm lỗi(nguyên lý 80-20)
Một số lượng nhỏ module core thường chứa hầu hết lỗi được phát hiện trước khi release
Hoặc chứa hầu hết các failures trong quá trình vận hành hoặc hoạt động.
(Nguyên lý: 80/20 80% lỗi được phát hiện thường nằm trong 20% module core)
Cụm lỗi được dự đoán cũng như dựa vào cụm lỗi thực tế tìm được trong khi test hoặc khi vận hành là đầu vào quan trọng được sử dụng cho phân tích rủi ro để tập trung test effort vào
Do vậy chúng ta cần phải xác định các module/chức năng/màn hình core, để tập trung effort test vào đó trong quá trình test.
5. Nguyên lý thuốc trừ sâu
Nếu chúng ta cứ thực hiện lặp đi lặp lại 1 bộ test thì cũng như dùng mãi 1 loại thuốc để tiêu diệt sâu, con sâu sẽ nhờn thuốc nên khả năng phát hiện ra lỗi mới là rất thấp. Do vậy chúng ta cần phải update bộ test mới để tăng khả năng phát hiện bug mới.
6. Kiểm thử tùy thuộc vào ngữ cảnh
Mỗi hệ thống đều được thực hiện trong các ngữ cảnh khác nhau.
Ví dụ, kiểm thử cho phần mềm công nghiệp khác với kiểm thử phần mềm giáo dục.
Tùy thuộc từng mô hình phát triển, kiểm thử trong hệ thống áp dụng mô hình Agile khác với kiểm thử áp dụng mô hình thác nước.
7. Sự vắng mặt của lỗi
Một số người/ tổ chức mong đợi teser có thể chạy hết tất cả các case, phát hiện ra tất cả các bug có thể có. Tuy nhiên điều đó là không thể. Và nhiều người tin tưởng rằng cứ tìm được nhiều lỗi thì sẽ đảm bảo được dự án thành công.
Thực tế không phải như vậy, nếu như việc test kỹ lưỡng tất cả các yêu cầu và fix các lỗi được tìm ra nhưng hệ thống vẫn khó sử dụng thì sẽ không đáp ứng được mong đợi của người dùng hoặc không có tính cạnh tranh với các hệ thống khác.
Nguyễn Thị Bích Cảnh