Test plan là gì? Cách viết kế hoạch kiểm thử theo 8 phần
Test plan không phải tài liệu viết cho có rồi cất đi. Nó tồn tại để trả lời một câu hỏi rất thực tế: với thời gian và người có hạn, đội sẽ kiểm thử cái gì, bỏ qua cái gì, và chấp nhận rủi ro nào.
Test plan là gì?
Test plan (kế hoạch kiểm thử) là tài liệu mô tả phạm vi, cách tiếp cận, nguồn lực và lịch trình cho các hoạt động kiểm thử của một dự án hoặc một đợt phát hành. Nó xác định cái gì sẽ được kiểm thử, ai làm, làm khi nào, bằng cách nào, và điều kiện nào để bắt đầu cũng như kết thúc.
Giá trị thật của test plan nằm ở phần "không làm gì". Một kế hoạch nói rõ "đợt này không kiểm thử hiệu năng vì lưu lượng dự kiến thấp" giúp cả đội biết rủi ro đang nằm ở đâu. Một kế hoạch chỉ liệt kê những thứ sẽ làm thì gần như vô dụng.
Phân biệt Test plan, Test strategy và Test case
| Tài liệu | Phạm vi | Trả lời câu hỏi | Tần suất thay đổi |
|---|---|---|---|
| Test strategy | Toàn tổ chức hoặc toàn sản phẩm | Chúng ta tiếp cận chất lượng theo triết lý nào? | Hiếm khi thay đổi |
| Test plan | Một dự án hoặc một đợt phát hành | Đợt này test gì, ai làm, khi nào, tiêu chí ra sao? | Mỗi dự án hoặc đợt phát hành |
| Test case | Một tình huống cụ thể | Nhập gì thì hệ thống phải trả về gì? | Liên tục |
8 phần của một test plan dùng được
Chuẩn IEEE 829 liệt kê rất nhiều mục, nhưng phần lớn dự án thực tế chỉ cần tám phần dưới đây. Thêm mục thì được, bớt mục thì nên cân nhắc.
1. Phạm vi kiểm thử (Scope)
Liệt kê rõ hai danh sách: những chức năng sẽ kiểm thử, và những chức năng cố ý không kiểm thử trong đợt này. Danh sách thứ hai quan trọng hơn và hay bị bỏ quên.
2. Cách tiếp cận (Test approach)
Sẽ dùng những cấp độ và loại kiểm thử nào, thủ công hay tự động, kỹ thuật thiết kế test case nào là chủ đạo.
3. Tiêu chí vào và tiêu chí ra (Entry / Exit criteria)
| Loại tiêu chí | Ví dụ cụ thể |
|---|---|
| Tiêu chí vào | Môi trường test sẵn sàng; bản build đã qua smoke test; tài liệu yêu cầu đã được duyệt |
| Tiêu chí ra | Đã thực thi 100% test case ưu tiên cao; không còn bug Critical hoặc Major mở; tỉ lệ pass tối thiểu 95% |
4. Rủi ro và biện pháp giảm thiểu
Phần thể hiện rõ nhất năng lực của người viết. Nêu rủi ro sản phẩm (chức năng nào hỏng thì thiệt hại lớn nhất) và rủi ro dự án (thiếu người, môi trường không ổn định, yêu cầu đổi liên tục), kèm cách xử lý.
5. Nguồn lực và phân công
6. Lịch trình và các mốc
7. Môi trường và dữ liệu test
8. Sản phẩm bàn giao (Deliverables)
Bộ test case, báo cáo thực thi, danh sách bug, báo cáo tổng kết.
Ưu tiên theo rủi ro — phần quan trọng nhất
Không bao giờ có đủ thời gian để test hết. Cách chọn đúng là chấm điểm từng chức năng theo hai trục: xác suất hỏng và mức thiệt hại nếu hỏng.
| Thiệt hại \ Xác suất | Thấp | Cao |
|---|---|---|
| Cao | Test kỹ, ưu tiên trung bình | Ưu tiên cao nhất — test sâu, test sớm |
| Thấp | Test nhẹ hoặc bỏ qua | Test ở mức cơ bản |
Ví dụ trong một ứng dụng thương mại điện tử: luồng thanh toán có thiệt hại cao và xác suất hỏng cao (nhiều tích hợp) nên phải test sâu nhất. Trang giới thiệu công ty có cả hai trục đều thấp nên chỉ cần kiểm tra hiển thị.
Test plan trong dự án Agile có gì khác?
Trong Agile, một tài liệu 30 trang viết một lần đầu dự án sẽ lỗi thời sau sprint thứ hai. Thay vào đó, kế hoạch được rút gọn và làm mới liên tục.
- Một test plan tổng ngắn gọn ở cấp sản phẩm — thường 1 đến 2 trang, nêu cách tiếp cận chung và tiêu chí chất lượng.
- Mỗi sprint có một kế hoạch nhỏ: sprint này test những story nào, rủi ro gì, cần dữ liệu gì.
- Định nghĩa hoàn thành (Definition of Done) đóng vai trò tiêu chí ra ở cấp story.
- Tiêu chí chấp nhận (Acceptance Criteria) của mỗi story chính là đầu vào để thiết kế test case.
Mẫu test plan rút gọn dùng ngay
KẾ HOẠCH KIỂM THỬ — Release 2.14 (Thanh toán & Giỏ hàng)
Người viết: ... | Ngày: ... | Phiên bản: 1.0
1. PHẠM VI
Sẽ test: Giỏ hàng, áp mã khuyến mãi, thanh toán thẻ, thanh toán ví
Không test: Thanh toán trả góp (chưa bật ở release này)
Đa ngôn ngữ (thị trường nước ngoài chưa mở)
2. CÁCH TIẾP CẬN
- System test thủ công cho các luồng nghiệp vụ mới
- API test cho 12 endpoint thanh toán (Postman)
- Regression tự động cho luồng đăng nhập và tìm kiếm (Playwright)
- Kỹ thuật chủ đạo: phân vùng tương đương, giá trị biên, bảng quyết định
3. TIÊU CHÍ VÀO
- Build đã qua smoke test
- Môi trường staging có dữ liệu mẫu và tài khoản test đủ 4 vai trò
- Tài liệu yêu cầu REQ-PAY-001..018 đã được duyệt
4. TIÊU CHÍ RA
- 100% test case Priority High đã thực thi
- Không còn bug Critical/Major ở trạng thái mở
- Tỉ lệ pass >= 95%
5. RỦI RO
R1 Cổng thanh toán sandbox không ổn định
-> Chuẩn bị bộ dữ liệu giả lập, báo sớm nếu sandbox lỗi quá 4 giờ
R2 Yêu cầu về quy tắc khuyến mãi chưa chốt
-> Lập bảng quyết định và gửi BA xác nhận trước ngày X
6. NGUỒN LỰC 2 tester, 8 ngày công
7. MÔI TRƯỜNG Staging, Chrome/Safari mới nhất, iOS 18 + Android 15
8. BÀN GIAO Bộ test case, báo cáo thực thi, danh sách bug, tổng kếtCâu hỏi thường gặp
Test plan và test strategy khác nhau thế nào?
Test strategy là tài liệu cấp tổ chức hoặc cấp sản phẩm, mô tả triết lý và cách tiếp cận chất lượng chung, hiếm khi thay đổi. Test plan ở cấp dự án hoặc đợt phát hành, nêu cụ thể đợt này test gì, ai làm, khi nào và tiêu chí vào ra là gì.
Ai là người viết test plan?
Thường là test lead hoặc QA manager với dự án lớn. Trong đội nhỏ hoặc dự án Agile, tester có kinh nghiệm nhất thường viết, và cả đội cùng rà soát. Người viết cần hiểu nghiệp vụ và nắm được rủi ro của sản phẩm.
Dự án Agile có cần test plan không?
Có, nhưng ở dạng rút gọn. Thay cho tài liệu dài viết một lần, Agile dùng một test plan tổng ngắn ở cấp sản phẩm cộng với kế hoạch nhỏ theo từng sprint. Định nghĩa hoàn thành và tiêu chí chấp nhận của story đóng vai trò tiêu chí ra ở cấp chi tiết.
Tiêu chí ra của kiểm thử nên đặt thế nào cho hợp lý?
Nên gồm cả tiêu chí định lượng và tiêu chí về rủi ro: đã thực thi hết test case ưu tiên cao, không còn bug nghiêm trọng ở trạng thái mở, và các rủi ro đã xác định đều đã được kiểm thử hoặc được chấp nhận có ghi nhận. Chỉ đặt mỗi tỉ lệ pass là chưa đủ.