Nguyên lý 1: Kiểm thử cho thấy sự hiện diện của lỗi

Kiểm thử có thể cho thấy sự có mặt của các lỗi, nhưng không thể chứng minh phần mềm không có lỗi. Kiểm thử giảm xác suất của các lỗi chưa được tìm thấy vẫn còn trong phần mềm.

Nguyên lý 2: Kiểm thử toàn bộ là không thể

Kiểm thử mọi thứ là không thực hiện được, trừ khi nó chỉ bao gồm một số trường hợp bình thường. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên mức độ ưu tiên để tập trung nỗ lực kiểm thử vào một số điểm cần thiết.

Nguyên lý 3: Kiểm thử sớm

Để tìm được các lỗi sớm nhất có thể, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong vòng đời phát triển phần mềm hoặc hệ thống.

Nguyên lý 4 – Sự tập trung của lỗi

Nỗ lực kiểm thử nên tập trung một cách cân đối vào mật độ lỗi dự kiến và lỗi phát hiện ra sau đó trong các mô-đun. Một số ít các mô-đun thường chứa nhiều lỗi không phát hiện ra trong lúc kiểm thử trước khi phát hành (release), hoặc chịu trách nhiệm cho hầu hết các lỗi hoạt động của phần mềm.

Để hiểu rõ hơn nguyên lý này, ta cần xem xét 3 điều sau:

     1.  Nguyên tắc tổ gián: chỗ nào có một vài con gián thì ở đâu đó xung quanh nó sẽ có cả tổ gián, có rất nhiều gián; chỗ nào có một vài bug thì xung quanh, gần gần chỗ đó sẽ có nhiều bug.

     2.  Nguyên tắc 80/20: thông thường 20% chức năng quan trọng trong một phần mềm có thể gây ra đến 80% tổng số bug phát hiện được trong phần mềm đó.

     3.  Kiểm thử toàn bộ là không thể (nguyên lý kiểm thử 2): do đó cần phải analysis (phân tích) + priorities (tính toán mức độ ưu tiên) để quyết định tập trung vào kiểm thử những chỗ nào.

     Trình tự kiểm thử có thể như sau: => Test kỹ chức năng quan trọng => tìm bug => test những gì liên quan và những chức năng gần nó để tìm ra bug nhiều hơn.

Nguyên lý thứ 5 – Nghịch lý thuốc trừ sâu

Nếu việc kiểm thử tương tự nhau được lặp đi lặp lại nhiều lần, thì cuối cùng sẽ có một số trường hợp kiểm thử (ca kiểm thử - test case) sẽ không còn tìm thấy bất kỳ lỗi nào mới. Để khắc phục "nghịch lý thuốc trừ sâu" này, các trường hợp kiểm thử cần phải được xem xét và sửa đổi thường xuyên, và cần phải viết các Test Cases mới và khác nhau để thực hiện kiểm thử nhiều phần khác nhau của phần mềm hoặc hệ thống để tìm ra lỗi tiềm ẩn nhiều hơn nữa.

Nguyên lý này giống như việc trừ sâu trong nông nghiệp, nếu chúng ta cứ phun một loại thuốc với nồng độ giống nhau trong một khoảng thời gian dài thì có một số con sâu sẽ quen dần và cuối cùng việc phun thuốc giống như là tắm chúng vậy (bị lờn thuốc), lúc đó chúng ta không thể diệt sạch chúng được. Do vậy, để diệt sạch sâu một cách hiệu quả, người ta thường thay đổi loại thuốc trừ sâu, mỗi loại chỉ dùng trong khoảng thời gian ngắn.

Nguyên lý 6 – Kiểm thử phụ thuộc vào ngữ cảnh

Nguyên tắc này nói lên việc kiểm thử phụ thuộc vào ngữ cảnh, tùy vào ngữ cảnh khác nhau mà mục tiêu và chiến lược kiểm thử của chúng ta cũng khác nhau, ví dụ: chiến lược kiểm thử một phần mềm kế toán sẽ khác với kiểm thử một trang web thương mại điện tử.

Nguyên lý 7 – Sai lầm về việc không có lỗi

Việc tìm và sửa chữa lỗi sẽ không giúp được gì nếu hệ thống được xây dựng xong nhưng không thể dùng được và không đáp ứng được nhu cầu và sự mong đợi của khách hàng. (Nghĩa là nếu sau khi code, test rồi fix bug, làm đủ tất cả các trường hợp và cuối cùng cho ra một sản phẩm hoạt động rất ổn định, ít lỗi nhưng lại không đáp ứng được nhu cầu của khách hàng hoặc sai ý khách hàng thì dự án phần mềm đó coi như thất bại cho dù phần mềm có đẹp đến đâu, có ổn định đến đâu,....). Quan trọng nhất là phần mềm phải đáp ứng theo yêu cầu khách hàng và khách hàng cảm thấy vui vẻ, hạnh phúc khi sử dụng phần mềm đó.

Mr. Phước Phan