Kế hoạch kiểm thử phần mềm: phạm vi, môi trường và tiêu chí dừng

Kế hoạch kiểm thử phần mềm trả lời bốn câu: kiểm cái gì, kiểm ở đâu, ai kiểm, và khi nào dừng. Một kế hoạch dùng được có tám phần, trong đó tiêu chí dừng phải viết thành con số kiểm tra được thay vì cảm nhận về mức độ ổn định.

Tóm tắt nhanh

• Kế hoạch kiểm thử là tài liệu quyết định, không phải danh sách kịch bản.
• Phạm vi phải nêu cả phần không kiểm thử, kèm lý do và rủi ro chấp nhận.
• Độ sâu kiểm thử nên chọn theo rủi ro nghiệp vụ, không chia đều cho mọi màn hình.
• Tiêu chí dừng cần ba loại số: số lỗi mở theo mức độ, tỷ lệ kịch bản đạt, và phạm vi đã phủ.
• Môi trường kiểm thử giống thật ở dữ liệu và tích hợp, không cần giống ở hạ tầng.

Bốn câu hỏi mà kế hoạch kiểm thử phải trả lời

Kiểm cái gì. Đây là phạm vi, gồm cả phần được kiểm và phần không được kiểm. Phần không được kiểm quan trọng ngang phần được kiểm, vì nó xác định rủi ro còn lại mà người phê duyệt phải chấp nhận.

Kiểm ở đâu. Đây là môi trường và dữ liệu. Một kịch bản đúng chạy trên môi trường sai sẽ cho kết quả vô nghĩa.

Ai kiểm. Đây là vai trò và trách nhiệm, gồm người viết kịch bản, người chạy, người xác nhận lỗi và người quyết định dừng.

Khi nào dừng. Đây là tiêu chí thoát. Không có tiêu chí này, việc kiểm thử kéo dài đến khi hết thời gian, và quyết định phát hành trở thành quyết định hành chính thay vì quyết định kỹ thuật.

Bốn câu này nghe đơn giản nhưng phần lớn kế hoạch trong thực tế chỉ trả lời câu thứ nhất và câu thứ ba, và đó là lý do các cuộc tranh luận về phát hành thường không có kết luận.

Tám phần của kế hoạch

Tám phần này đủ cho một đợt kiểm thử từ một tuần đến vài tháng. Với đợt rất nhỏ, có thể gộp phần 5 và 6, nhưng không nên bỏ phần 2 và phần 7.

Phạm vi: ma trận độ sâu theo rủi ro

Cách phân bổ nguồn lực hiệu quả là chấm rủi ro cho từng nhóm chức năng, rồi chọn độ sâu tương ứng. Rủi ro ở đây là tổ hợp của mức ảnh hưởng khi sai và khả năng sai.

Ma trận này có hai tác dụng. Thứ nhất, nó biện minh cho việc không kiểm thử sâu mọi thứ. Thứ hai, nó tạo ra danh sách rủi ro còn lại để người phê duyệt xem trước khi phát hành.

Môi trường: ba môi trường tối thiểu

Ba môi trường này là mức tối thiểu cho hệ thống có tích hợp bên ngoài. Với hệ thống nhỏ, có thể gộp môi trường thử nghiệm và tiền phát hành, nhưng phải chấp nhận rủi ro là cấu hình thật khác cấu hình thử.

Hai yêu cầu quan trọng với môi trường. Thứ nhất, dữ liệu phải tạo lại được, để mỗi đợt kiểm thử bắt đầu từ cùng một trạng thái. Thứ hai, tích hợp bên ngoài phải có chế độ giả lập, để kiểm thử không phụ thuộc vào dịch vụ thật và không tạo giao dịch thật.

Tiêu chí dừng viết thành con số

Ví dụ một đợt kiểm thử có 480 kịch bản, trong đó 120 kịch bản thuộc nhóm rủi ro cao. Tiêu chí dừng có thể viết như sau.

Về lỗi: không còn lỗi mức nghiêm trọng nào ở trạng thái mở; không quá hai lỗi mức cao ở trạng thái mở, và cả hai phải có phương án xử lý tạm được người phụ trách nghiệp vụ chấp nhận.

Về tỷ lệ đạt: ít nhất 95% kịch bản đã chạy và đạt, tính trên toàn bộ 480 kịch bản. Với nhóm rủi ro cao, tỷ lệ đạt phải là 100%, không có ngoại lệ.

Về phạm vi phủ: toàn bộ 120 kịch bản rủi ro cao đã chạy ít nhất một lần trên môi trường thử nghiệm, và các luồng chính đã chạy trên môi trường tiền phát hành.

Ba con số này có quan hệ với nhau. Nếu tỷ lệ đạt 95% nhưng hai lỗi cao còn mở, chưa đạt. Nếu không còn lỗi cao nhưng tỷ lệ đạt chỉ 88%, cũng chưa đạt. Cách viết này buộc phải nhìn cả ba chiều thay vì chọn chiều dễ nhất.

Một lưu ý về cách tính tỷ lệ: mẫu số phải cố định trước khi bắt đầu. Nếu mẫu số thay đổi trong quá trình kiểm thử, tỷ lệ trở thành con số vô nghĩa. Cách xử lý là chốt danh sách kịch bản ở một mốc, và mọi kịch bản thêm sau đó ghi vào danh sách riêng.

Ai ký và khi nào dừng thật

Tiêu chí dừng là điều kiện cần, không phải điều kiện đủ. Quyết định phát hành cần ba chữ ký, mỗi chữ ký trả lời một câu khác nhau.

Người phụ trách kiểm thử xác nhận tiêu chí dừng đã đạt, kèm báo cáo số liệu. Đây là chữ ký về sự thật, không phải về quyết định.

Người phụ trách nghiệp vụ xác nhận các lỗi còn mở và rủi ro còn lại là chấp nhận được. Đây là chữ ký về mức độ ảnh hưởng.

Người phụ trách vận hành xác nhận môi trường, sao lưu, giám sát và cách quay lui đã sẵn sàng. Đây là chữ ký về khả năng xử lý khi có sự cố.

Thiếu chữ ký thứ hai, quyết định phát hành trở thành quyết định kỹ thuật thuần tuý và thường bỏ qua tác động nghiệp vụ. Thiếu chữ ký thứ ba, hệ thống có thể phát hành mà không có cách quay lui.

Năm lỗi khiến kế hoạch không dùng được

Phạm vi chỉ có phần kiểm. Không nêu phần không kiểm thì không ai biết rủi ro còn lại là gì.

Tiêu chí dừng viết bằng tính từ. "Ổn định", "chấp nhận được", "không còn lỗi nghiêm trọng" đều cần định nghĩa. Không định nghĩa thì mỗi người hiểu một cách.

Dùng dữ liệu thật không kiểm soát. Dữ liệu khách hàng thật trong môi trường thử tạo ra rủi ro bảo mật và rủi ro sai lệch số liệu khi thao tác thử.

Không có kịch bản cho luồng lỗi. Phần lớn sự cố xảy ra ở luồng lỗi: mất kết nối, thanh toán bị từ chối, dữ liệu trùng. Chỉ kiểm luồng chính là kiểm phần dễ nhất.

Kế hoạch không được cập nhật khi phạm vi thay đổi. Phạm vi đổi mà kế hoạch không đổi thì tiêu chí dừng không còn phản ánh rủi ro thật.

Câu hỏi thường gặp

Kế hoạch kiểm thử khác kịch bản kiểm thử ở đâu?

Kế hoạch là tài liệu cấp đợt, xác định phạm vi, môi trường, vai trò và tiêu chí dừng. Kịch bản là tài liệu cấp từng trường hợp, mô tả bước thực hiện và kết quả mong đợi. Một kế hoạch có thể bao gồm hàng trăm kịch bản. Viết kế hoạch trước giúp biết cần bao nhiêu kịch bản và ai viết.

Có cần kiểm thử tự động cho mọi thứ không?

Không. Nên ưu tiên tự động hoá cho phần chạy lại nhiều lần và phần có rủi ro cao: luồng thanh toán, phân quyền, tính toán số liệu, giao diện lập trình với hệ thống bên ngoài. Phần giao diện thay đổi nhanh thường tốn chi phí bảo trì lớn hơn lợi ích, nên kiểm thử thủ công có kiểm soát là lựa chọn hợp lý.

Tiêu chí dừng nên đặt bao nhiêu lỗi mở?

Không có con số chung. Cách xác định là dựa trên mức ảnh hưởng: lỗi chặn luồng chính hoặc ảnh hưởng tiền phải bằng không; lỗi ảnh hưởng một phần luồng phụ có thể chấp nhận một số lượng nhỏ, kèm phương án xử lý tạm và người chấp nhận rủi ro. Điều quan trọng là con số được viết trước khi kiểm thử, không điều chỉnh sau khi thấy kết quả.

Môi trường thử nghiệm có cần giống môi trường thật hoàn toàn không?

Không cần giống ở hạ tầng, nhưng cần giống ở dữ liệu và tích hợp. Khác biệt về cấu hình máy chủ thường ít ảnh hưởng đến kết quả nghiệp vụ. Khác biệt về dữ liệu và tích hợp thì ảnh hưởng trực tiếp, vì phần lớn lỗi phát sinh ở chỗ giao nhau giữa các hệ thống.

Cập nhật và kiểm chứng

Cập nhật tháng 11/2026; hai văn bản dưới đây được đối chiếu ở phần nghiệm thu và phần xử lý khi một bên không thực hiện đúng cam kết.

• Bộ luật Dân sự số 91/2015/QH13 — vanban.chinhphu.vn
• Luật Thương mại số 36/2005/QH11 — vanban.chinhphu.vn

Đây không phải tư vấn pháp lý hay tư vấn thuế. Tiêu chí và mức độ kiểm thử phù hợp phụ thuộc vào sản phẩm và mức rủi ro chấp nhận được; nội dung bài viết là khung tham chiếu, không phải chuẩn bắt buộc.

Bài viết liên quan: kịch bản kiểm thử phần mềm, test case là gì trong kiểm thử phần mềm, quy trình phát triển phần mềm là gì và thuế GTGT của phần mềm là bao nhiêu.

Nếu bạn cần một kế hoạch kiểm thử có tiêu chí dừng rõ trước khi phát hành, WinSell xây dựng phần mềm theo yêu cầu theo bốn giai đoạn Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.