7 Nguyên tắc kiểm thử phần mềm một cách nhìn khác (phần 2)

Trong bài trước, chúng ta đã tìm hiểu 3 trong 7 nguyên tắc kiểm thử phần mềm, trong bài này chúng ta sẽ tìm hiểu tiếp 4 nguyên tắc kiểm thử phần mềm còn lại

4. Bug clustering (Lỗi thì thường tập trung tại một vài tính năng)

Nguyên tắc này được hiểu là, trong một hệ thống phần mềm, sẽ có một hoặc một vài tính năng sẽ chiếm phần lớn các lỗi xẩy ra. Nguyên tắc này tương đồng với nguyên tắc 80/20, 80% số lỗi sẽ được phát hiện trong 20% số tính năng.

Nguyên nhân để có nguyên tắc này là

• Trong một dự án phần mềm, không phải tất cả các tính năng đều có sự phức tạp như nhau. Các tính năng có độ phức tạp cao hơn thường sẽ gây ra nhiều lỗi hơn các thành phần còn lại.
• Do yếu tố con người, trong dự án các thành viên thường không có kỹ năng tương đồng, các thành viên có kỹ năng thấp hơn có nguy cơ gây lỗi cao hơn các thành viên có kỹ năng cao.

Hiểu được nguyên tắc này, kiểm thử viên sẽ đưa ra chiến lược test phù hợp trong dự án. Ví dụ: sau 1 tuần tiến hành kiểm thử, kiểm thử viên tiến hành phân tích và thấy một số function có tỷ lệ lỗi cao hơn, tại thời điểm đó bạn kiểm thử viên có thể quyết định tập trung hơn vào các tính năng gặp nhiều lỗi để có thể bắt lỗi triệt để hơn.

Kiểm thử viên cũng có thể phân tích độ phức tạp của các tính năng trong dự án ngay từ đầu dự án để từ đó bố trí nguồn lực có kinh nghiệm để nâng cao chất lượng và phát hiện lỗi sớm tại những tính năng đó.

5. Pesticide paradox (Hiệu ứng thuốc trừ sâu)

Nguyên tắc này nói lên rằng, nếu bạn cứ mang một bộ test case, checklist, test data ra thực hiện test đi test lại thì sau một thời gian bộ tài liệu test đó sẽ không thể phát hiện thêm lỗi mới nữa. Để có thể phát hiện thêm lỗi mới thì cần phải bổ xung quan điểm test mới, test case mới, test data mới.

Nguyên tắc này cũng được hiểu là nếu một kiểm thử viên có thời gian làm việc quá dài với một phần mềm mà không có sự thay đổi về tư duy kiểm thử thì tỷ lệ lỗi mà người đó phát hiện được sẽ giảm dần theo thời gian.

6. Testing is context dependent (Kiểm thử phụ thuộc ngữ cảnh)

Mỗi phần mềm có môi trường làm việc khác nhau và có yêu cầu kiểm thử khác nhau. Do dó kiểm thử không thể giống nhau với tất cả các phần mềm. Phần mềm thương mại điện tử thì tập trung vào khả năng tìm kiếm sản phẩm, thanh toán… Còn phần mềm trong y tế thì tập trung vào việc tìm kiếm bệnh lý và đảm bảo an toàn cho bệnh nhân.

Với nguyên tắc này, kiểm thử viên phải hiểu được rằng mỗi một phần mềm đều phải có cách tiếp cận khác nhau từ đó họ phải xây dựng được chiến lược kiểm thử phù hợp cho từng sản phẩm phần mềm mà mình phải xử lý.

7. Absence-of-errors is a fallacy (Nguỵ biện về việc không có lỗi)

Cho dù tất cả các lỗi đã được fix, không còn lỗi trong sản phẩm phần mềm thì việc thành công của sản phầm phần mềm hoàn toàn không phụ thuộc vào điều đó. Sản phẩm đó có thể không phù hợp với thực tế, khó khăn với người sử dụng hoặc bị lỗi thời do phát triển quá dài. Do đó việc nguỵ biện sản phẩm không có lỗi là một sản phẩm thành công là không đúng thực tế.

Trên đây là 7 nguyên tắc trong kiểm thử phần mềm, 7 kim chỉ nam mà bất kỳ kiểm thử viên nào cũng phải nắm chắc. Nếu có điểm gì chưa hiểu hay cùng tham gia group của IT Learn để tra đổi nhé

Facebook group: IT Learn – Chia sẻ kiến thức công nghệ thông tin | Facebook

Facebook page: It Learn | Hanoi | Facebook

Tham khảo: Certified Tester Foundation Level (istqb.org)

Bài trước: 7 Nguyên tắc kiểm thử phần mềm, một cách nhìn khác (phần 1) – IT LEARN