Trong kiểm thử phần mềm, về cơ bản có 7 nguyên tắc chính bạn có thể biết. Tìm hiểu chúng giúp bạn biết thêm kiến thức về testing, tiết kiệm thời gian cũng như công sức truy lùng bug ẩn trong các ứng dụng của bạn,…

1. Kiểm thử đưa ra lỗi (lỗi hiện diện ở tất cả mọi nơi) - Show presence of error

Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi. Kiểm thử được thực hiện bằng những kĩ thuật khác nhau. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm, ngay cả khi đã kiểm thử nghiêm ngặt phần mềm vẫn có thể còn lỗi. Vì vậy chúng ta phải tìm được càng nhiều lỗi càng tốt.

2. Kiểm thử cạn kiệt là không thể - Exhaustive testing is impossible

Nguyên tắc này giải thích cho câu bạn hay hỏi “tại sao test kĩ vậy, test mãi mà vẫn có bug’ Nguyên tắc này nói rằng kiểm tra mọi thứ trong phần mềm một cách trọn vẹn là không thể. Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là không thể trừ phi nó chỉ bao gồm ít trường hợp thì có thể kiểm thử toàn bộ. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn.

3. Kiểm thử càng sớm càng tốt - Early testing

Nguyên tắc này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầu của vòng đời phát triển phần mềm. Có thể là ngay từ giai đoạn phân tích yêu cầu nghiệp vụ. Các hoạt động kiểm thử phần mềm từ giai đoạn đầu sẽ giúp phát hiện bug sớm hơn. Nó cho phép chuyển giao phần mềm theo yêu cầu đúng thời gian với chất lượng và chí phí dự kiến.

4. Sự tập trung của lỗi - Defect clustering

Thông thường, lỗi tập trung vào những module, thành phần chức năng chính của hệ thống. Nếu xác định được điều này bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định. Là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả khi mà dự án không đủ thời gian cũng như nguồn lực trong thời gian ngắn để kịp thời gian bàn giao chức năng.

5. Nghịch lý thuốc trừ sâu - Pesticide paradox

Nếu bạn sử dụng cùng một tập hợp các trường hợp kiểm thử liên tục, sau đó một thời gian các trường hợp kiểm thử không tìm thấy lỗi nào mới. Hiệu quả của các trường hợp kiểm thử bắt đầu giảm xuống sau một số lần thực hiện, vì vậy luôn luôn chúng ta phải luôn xem xét và sửa đổi các trường hợp kiểm thử trên một khoảng thời gian thường xuyên.

6. Kiểm thử phụ thuộc vào ngữ cảnh - Testing is context dependent

Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào ngữ cảnh và chúng ta phải tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau Nếu bạn đang kiểm thử ứng dụng web và ứng dụng di động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì đó là sai. Chiến lược để kiểm thử ứng dụng web sẽ khác với kiểm thử ứng dụng cho thiết bị di động của Android.

7. Sai lầm khi không có lỗi - Absence of errors fallacy

Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới.

Kết luận

Kiểm thử không phải chỉ đơn thuần là một hoạt động riêng lẻ mà là một loạt các hoạt động liên quan và bổ sung cho nhau và phức tạp. Tuy nhiên, việc dựa theo 7 nguyên tắc trên sẽ giúp cho bạn có cái nhìn tổng quát hơn về kiểm thử cũng như giúp bạn đánh giá được tính hiệu quả của hoạt động kiểm thử được thực thi.