Bảy nguyên tắc cơ bản của Kiểm thử phần mềm

Nội dung: nói và diễn giải về bảy nguyên tắc cơ bản trong testing software. Bài này là bài lý thuyết bổ sung và tester phải nắm được nằm lòng các nguyên tắc này!

Bảy nguyên tắc (như khẩu huyết trong võ công):

1. Kiểm thử tất cả mọi trường hợp là không thể được. (EXHAUSTIVE testing is not possible).
   Giải thích như sau: Một form có textbox cho phép nhập từ 1 -> 1.000.000.000.000. Nếu để kiểm thử nhập liệu cho textbox này ta phải kiểm thử 1k tỷ lần. Mỗi thao tác nhập cho là 1 giây, và phép toán kiểm tra nhập liệu là 0.1 giây nữa thì ta phải mất xấp xỉ 1k tỷ giây là khoảng 31k năm để thực thi nó. Đời người chỉ khoảng một trăm năm, vậy phải mất cả mấy nghìn đời để thực thi kiểm tra một textbox mà chưa kể đến nhiều đối tượng khác cho nên mới nói điều này là không thể làm được! (Chi phí nuôi nghìn người và giá trị bỏ ra là không xứng).
   Để xử lý thì ta: dùng kỹ thuật phân vùng tương đương, Phân nhánh nghiệp vụ, chia lớp xử lý... (Sẽ nói chi tiết sau).
2. Kiểm thử là chỉ ra sai sót đang có (Testing shows presence of defects).
   Giải thích như sau:
   Trường hợp a: Tester tìm ra lỗi trong phần mềm tính toán ở phép cộng =>Có lỗi ở phép cộng nhưng không ai chắc chắn là không có lỗi ở phép trừ.
   Trường hợp b: Tester không tìm thấy lỗi trên phần mềm tính toán ở phép cộng, trừ, nhân, chia => Không có lỗi ở phần phép toán nhưng ai dám khẳng định là phần nhập liệu không có lỗi? ( Lỗi này xảy ra người ta gọi là lỗi tìm ẩn).
   Cho nên nói, việc kiểm thử phần mềm chỉ nhằm mục đích chỉ ra lỗi đang hiện có ở phần mềm, chứ không chỉ ra rằng phần mềm không có lỗi. (ai bảo phần mềm của tôi không có lỗi thì đấm phát chết luôn).
3. Kiểm thử sớm. (Early testing)
   Giải thích như sau:
   Thực hiện kiểm thử càng sớm lỗi phát hiện càng sớm và được sửa sớm thì sẽ ngăn chặn hậu quả sau này của nó lớn hơn.
   Ví dụ cho một phần mềm kiểm soát máy bay. Nếu trong quá trình phát triển chúng ta không sớm phát hiện lỗi nhỏ: một phép cộng bị sai (ví dụ), và khi quy trình thật vận dụng thì lỗi này xảy ra làm máy bay bị lật nhào trên không. Và chi phí lúc đó rà soát lại là: chi phí thu hồi máy bay, sửa lỗi phần mềm, cài đặt lại ... => Nhưng nếu ở giai đoạn phát triển ta triệt tiêu lỗi này, chi phí sẽ rẻ hơn nhiều.
4. Phân vùng bug (Defect clustering)
   Giải thích như sau: Lỗi hay xuất hiện và tập trung thành nhiều vùng trên hệ thống. Ví dụ: Ứng dụng máy tính đang bị lỗi ở phép tính cộng, thì có thể phép tính trừ, nhân chia cũng đang bị lỗi.
5. Kiểm thử lệ thuộc vào ngữ cảnh (Testing is context depending).
   Giải thích như sau: Mỗi hệ thống làm một nhiệm vụ khác nhau, nên mỗi khi test ta phải có một sự lệ thuộc ngữ cảnh khác nhau. Ví dụ: ta test hệ thống bảo mật thì ngữ cảnh này ta phải quan tâm đến: bảo mật hệ thống, hacking, ... khi ta test hệ thống bán hàng online: thì ta quan tâm đến giỏ hàng, tiền, bảo mật giao dịch...
6. Nghịch lý thuốc trừ sâu (Pesticide paradox).
   Giải thích như sau: Test 1 case mà dev fixed rồi thì không còn bug nữa. (Như sâu bị phun thuốc trừ sâu nhiều thì bị lờn thuốc.) Do vậy nên bắt sâu bằng tay, hoặc tạo testcase mới nếu có yêu cầu test lại.
7. Ảo tưởng về lỗi. (Absence – of – errors fallacy).
   Giải thích như sau: Test cho hệ thống thật hay ít bug mà nhu cầu không phù hợp với người dùng thì cũng bằng không. Thay vì vậy đứng vào con mắt của người dùng mà làm việc.

Trong kiểm thử bảy nguyên tắc này đi hết tất cả các quy trình của dự án test, làm nền tảng cho lý thuyết của testing software. Hầu hết những gì sẽ học đa số đều liên quan đến nó, vậy nhất thiết khi học testing software phải biết bảy nguyên tắc này!