Nhiều người cho rằng mục tiêu duy nhất của testing là tìm bug. Trên thực tế, kiểm thử còn giúp đánh giá tài liệu, giảm rủi ro, cung cấp thông tin và xây dựng niềm tin về chất lượng sản phẩm.

Theo ISTQB, các mục tiêu kiểm thử (test objectives) thường gặp gồm:

1. Đánh giá các sản phẩm công việc (work products)

Testing có thể đánh giá cả requirement, user story, thiết kế và source code trước cả khi phần mềm hoàn chỉnh.

Ví dụ: Review SRS phát hiện hai yêu cầu mô tả khác nhau về thời hạn thanh toán -> Xử lý sớm trước khi code

Note: “Sản phẩm công việc” bạn hiểu đơn giản là những thứ khác trong dự án như requirement, user story, thiết kế và source code

2. Kích hoạt failure và tìm defect

Tester thiết kế các kịch bản phù hợp để làm lộ ra hành vi sai và xác định khiếm khuyết trong sản phẩm.

Ví dụ: Nhập số lượng âm khiến tổng tiền đơn hàng bị tính sai. Do dev không handle trường hợp số âm mà chỉ test các happy case

3. Đảm bảo mức coverage cần thiết

Kiểm thử cần bao phủ những yêu cầu, nhánh xử lý, rủi ro hoặc môi trường đã được xác định trong test plan.

Ví dụ: Đảm bảo tất cả business rule của chức năng tính thuế đều có ít nhất một test case.

4. Giảm rủi ro về chất lượng phần mềm (reduce risk)

Testing giúp giảm xác suất xảy ra failure hoặc giảm tác động của chúng bằng cách ưu tiên các khu vực có rủi ro cao.

Ví dụ: Kiểm thử kỹ thanh toán trước ngày sale lớn để giảm nguy cơ mất doanh thu. Hoặc kiểm thử load test hàng ngàn user trước ngày Black Friday để đảm bảo hệ thống không bị sập trong ngày đó

5. Xác minh các yêu cầu đã được đáp ứng

Tester kiểm tra sản phẩm có thực hiện đúng những yêu cầu đã được quy định hay không.

Ví dụ: Yêu cầu quy định tài khoản bị khóa sau 5 lần đăng nhập sai; test xác nhận hệ thống hoạt động đúng như vậy. Nói chung là phải đảm bảo là phần mềm phải chuẩn theo yêu cầu tài liệu

6. Xác minh sự tuân thủ (compliance)

Sản phẩm có thể phải tuân thủ hợp đồng, pháp luật, quy định ngành hoặc tiêu chuẩn nội bộ.

Ví dụ: Kiểm tra hệ thống không lưu thông tin thẻ thanh toán nhạy cảm trái với quy định bảo mật. Và hệ thống phải tuân thủ pháp luật hiện hành (ví dụ hệ thống cờ bạc, cá độ.. thì bạn phải né ngay 😂)

7. Cung cấp thông tin cho stakeholder

Kết quả kiểm thử giúp stakeholder đưa ra quyết định dựa trên dữ liệu thay vì cảm tính.

Ví dụ: Báo cáo còn hai lỗi Critical ở luồng thanh toán để Product Owner quyết định hoãn release. Hoặc nếu chỉ phát hiện lỗi nhỏ -> hoàn toàn có khả năng release được

8. Xây dựng niềm tin vào chất lượng sản phẩm (confidence)

Kết quả test tích cực và bằng chứng coverage giúp đội dự án tin tưởng hơn rằng sản phẩm đủ ổn định để sử dụng hoặc phát hành.

Ví dụ: Regression suite pass trên các trình duyệt được hỗ trợ trước khi triển khai production.

9. Xác nhận sản phẩm đáp ứng mong đợi của stakeholder

Phần mềm không chỉ cần đúng đặc tả mà còn phải đầy đủ, hữu ích và hoạt động đúng với nhu cầu thực tế.

Ví dụ: Người dùng nghiệp vụ thực hiện UAT và xác nhận quy trình xuất hóa đơn phù hợp với công việc hằng ngày.

Mục tiêu kiểm thử có luôn giống nhau không?

Không. Mục tiêu cụ thể phụ thuộc vào bối cảnh dự án, test level, loại sản phẩm và rủi ro. Unit testing có thể tập trung vào defect trong code, trong khi acceptance testing tập trung nhiều hơn vào nhu cầu nghiệp vụ và khả năng đưa sản phẩm vào sử dụng.

Hiểu rõ mục tiêu giúp đội dự án lựa chọn đúng kỹ thuật, phạm vi và tiêu chí kết thúc kiểm thử — thay vì chỉ chạy thật nhiều test case mà không biết chúng phục vụ quyết định nào.