Trước khi bắt tay test, đội QA luôn cần một bản kế hoạch — và đó là lúc câu hỏi test plan là gì trở nên quan trọng. 🙂 Test plan giúp cả đội biết test cái gì, ai làm, đến đâu thì dừng, và rủi ro nào cần canh — một kỹ năng nền khi học Manual Testing. Bài này tôi giải thích định nghĩa, các thành phần chuẩn, cách lập từng bước theo góc nhìn quản lý kiểm thử (ISTQB CTAL-TM), kèm ví dụ và khung template để bạn áp dụng ngay.
Test plan là gì?
Test plan (kế hoạch kiểm thử) là tài liệu mô tả mục tiêu, phạm vi, cách tiếp cận, nguồn lực và lịch trình cho hoạt động kiểm thử của một dự án hoặc một đợt test. Theo ISTQB, test plan ghi lại phương tiện và lịch trình để đạt mục tiêu test, giúp đảm bảo việc test bám sát các tiêu chí đã đặt, và là công cụ giao tiếp với các bên liên quan. Trong quy trình kiểm thử (STLC), test plan chính là đầu ra của bước lập kế hoạch (Test Planning).
Một điểm nhiều người mới chưa nắm: theo CTAL-TM, việc lập test plan nên bắt đầu càng sớm càng tốt — lý tưởng là trước cả khi yêu cầu được chốt — và là một hoạt động lặp lại, cần cập nhật liên tục khi dự án thay đổi. Test plan không phải tài liệu viết một lần rồi cất tủ, mà là bản kế hoạch sống.
Test plan gồm những phần nào (theo IEEE 829)
Cấu trúc test plan kinh điển được mô tả trong tiêu chuẩn IEEE 829 — vẫn được dùng rộng rãi làm khung tham khảo:
| # | Thành phần (IEEE 829) | Nội dung chính |
|---|---|---|
| 1 | Test plan identifier | Mã định danh và phiên bản của tài liệu test plan |
| 2 | Introduction | Giới thiệu, mục tiêu và phạm vi tổng quan |
| 3 | Test items | Các hạng mục/sản phẩm sẽ test (kèm phiên bản) |
| 4 | Features to be tested | Tính năng nằm trong phạm vi test |
| 5 | Features not to be tested | Tính năng ngoài phạm vi (và lý do) |
| 6 | Approach | Cách tiếp cận: test level, test type, kỹ thuật, công cụ |
| 7 | Item pass/fail criteria | Tiêu chí đạt / không đạt |
| 8 | Suspension & resumption criteria | Điều kiện tạm dừng và nối lại test |
| 9 | Test deliverables | Sản phẩm bàn giao (test case, báo cáo…) |
| 10 | Testing tasks | Các công việc test cần thực hiện |
| 11 | Environmental needs | Môi trường, phần cứng/phần mềm, dữ liệu test |
| 12 | Responsibilities | Phân công trách nhiệm |
| 13 | Staffing & training needs | Nhân sự và nhu cầu đào tạo |
| 14 | Schedule | Lịch trình và các mốc thời gian |
| 15 | Risks & contingencies | Rủi ro và phương án dự phòng |
| 16 | Approvals | Phê duyệt, chữ ký các bên |
Lưu ý chuẩn hoá: IEEE 829 (bản 2008) nay đã được thay thế bởi bộ tiêu chuẩn ISO/IEC/IEEE 29119 (29119-2 cho quy trình, 29119-3 cho tài liệu). Theo ISTQB, nội dung test plan gồm: bối cảnh test; giả định & ràng buộc; stakeholders; cách giao tiếp; risk register; test approach (test level, test type, kỹ thuật, deliverables, entry/exit criteria, mức độ độc lập của test, metrics, yêu cầu dữ liệu & môi trường); ngân sách và lịch.
Test plan có nhiều cấp. CTAL-TM nhấn mạnh việc lập kế hoạch có thể ở cấp dự án, chương trình (program) hay danh mục (portfolio). Mỗi cấp có thể có test plan riêng và phải ăn khớp với test plan cấp cao hơn — ví dụ một master test plan bao quát cả dự án, bên dưới là các test plan cho từng test level (system test plan, UAT plan…).
Cách lập test plan từng bước
Theo CTAL-TM, lập test plan thực chất là một chuỗi nhiệm vụ (tương tự ISO/IEC/IEEE 29119-2):
- Hiểu bối cảnh & tổ chức việc lập kế hoạch. Nắm test policy và chiến lược test của tổ chức, phạm vi test, và test item (sản phẩm cần test). Sau đó tổ chức việc soạn plan và lấy phê duyệt của stakeholders (product owner, PM, trưởng nhóm dev).
- Nhận diện & phân tích rủi ro sản phẩm. Xác định và đánh giá khả năng xảy ra (likelihood) và mức ảnh hưởng (impact) của từng rủi ro để xác định risk level.
- Chọn cách xử lý rủi ro. Dựa trên phân tích rủi ro, chọn biện pháp: phòng ngừa (preventive), khắc phục (corrective) hoặc giảm thiểu (mitigating) — và ghi vào plan.
- Định nghĩa test approach + ước lượng & phân bổ nguồn lực. Dựa trên chiến lược test của tổ chức, ràng buộc dự án và cách xử lý rủi ro, xác định cách tiếp cận test cho phạm vi hiện tại; ước lượng nhân sự, công cụ, môi trường, dữ liệu test và phân bổ vào các hoạt động.
- Thiết lập & chốt test plan. Plan phải được mọi stakeholder chấp nhận; mọi bất đồng cần được giải quyết trước khi thực thi.
Đặt mục tiêu & exit criteria theo S.M.A.R.T
CTAL-TM khuyến nghị dùng phương pháp S.M.A.R.T để mục tiêu test và exit criteria đo lường được: Specific (cụ thể), Measurable (đo được), Achievable (khả thi), Relevant (liên quan), Time-bound (có thời hạn). Ví dụ thay vì "test kỹ chức năng đăng nhập", hãy viết "chạy 100% test case ưu tiên Cao của module đăng nhập trước cuối Sprint 12, không còn bug Critical/High".
Phân bổ công sức theo rủi ro (risk-based)
Nguyên tắc cốt lõi: công sức test tỉ lệ thuận với mức rủi ro. Vùng rủi ro cao nên test sớm và dùng kỹ thuật nghiêm ngặt hơn; vùng rủi ro thấp có thể test muộn hơn, nhẹ hơn. Khi ưu tiên thực thi, có hai cách: depth-first (chạy theo thứ tự rủi ro giảm dần — hợp khi cần dập rủi ro cao nhất sớm) và breadth-first (mỗi rủi ro chạy ít nhất một test — hợp khi cần bức tranh chất lượng tổng thể sớm). Báo cáo theo rủi ro còn lại (residual risk) giúp stakeholder ra quyết định release.
Ước lượng công sức test
CTAL-TM chia kỹ thuật ước lượng thành hai nhóm: metric-based (dựa trên dữ liệu/số liệu lịch sử, ví dụ extrapolation, tỉ lệ, three-point estimation) và expert-based (dựa trên ý kiến chuyên gia, ví dụ Wideband Delphi, planning poker). Chọn kỹ thuật theo bối cảnh: dự án Agile thường dùng planning poker; mô hình tuần tự thường dùng Wideband Delphi.
Ví dụ test plan rút gọn
Khung template rút gọn cho một đợt test chức năng đăng nhập của "Hệ thống đặt phòng họp nội bộ" — bạn copy và điền theo dự án:
TEST PLAN — Đăng nhập (Sprint 12)
1. Mục tiêu (S.M.A.R.T): 100% test case ưu tiên Cao của module đăng nhập
được chạy trước cuối Sprint 12; không còn bug Critical/High.
2. Phạm vi:
- Test: đăng nhập đúng/sai, validation, bảo mật cơ bản (chống user enumeration).
- Không test: SSO, đăng nhập mạng xã hội (chưa phát triển).
3. Cách tiếp cận (risk-based): ưu tiên vùng rủi ro cao (bảo mật, xác thực) —
test sớm, kỹ thuật nghiêm ngặt; phân vùng tương đương + giá trị biên.
4. Tiêu chí:
- Entry: build đã deploy lên staging, smoke test pass.
- Exit: đạt mục tiêu mục 1; rủi ro còn lại được stakeholder chấp nhận.
5. Môi trường: Chrome mới nhất; tài khoản test mẫu; môi trường staging.
6. Ước lượng & nguồn lực: 1 tester, 2 ngày (ước lượng bằng planning poker).
7. Rủi ro & xử lý: thiếu dữ liệu test → chuẩn bị trước (preventive);
phụ thuộc API auth → xác nhận sẵn sàng (mitigating).
8. Deliverables: bộ test case, báo cáo kết quả test, báo cáo rủi ro còn lại.
Sau khi có test plan, bước tiếp theo là chi tiết hoá thành test case — xem hướng dẫn cách viết test case.
Test plan vs Test strategy
Đây là chỗ rất hay nhầm, và CTAL-TM phân biệt khá rạch ròi giữa ba khái niệm:
- Organizational test strategy (chiến lược test của tổ chức): mức cao nhất, mô tả cách tổ chức thực hiện kiểm thử nói chung — ổn định, ít thay đổi.
- Test strategy (chiến lược test): mô tả cách kiểm thử sẽ được thực hiện để đạt mục tiêu test trong một bối cảnh cụ thể; có thể nằm trong test plan hoặc tài liệu khác, và có thể tồn tại cho riêng một test level hay test type.
- Test approach (cách tiếp cận test): cách thức hiện thực việc test (ví dụ manual testing, back-to-back testing). Chọn test approach là quyết định then chốt khi hình thành chiến lược test.
| Tiêu chí | Test Strategy | Test Plan |
|---|---|---|
| Cấp độ | Tổ chức / sản phẩm / level, tổng quát | Dự án / đợt test cụ thể |
| Trả lời câu hỏi | Kiểm thử kiểu gì, theo nguyên tắc nào | Test cái gì, ai, khi nào, bằng gì |
| Tần suất thay đổi | Ít thay đổi, ổn định | Theo từng dự án/đợt, cập nhật liên tục |
| Người phụ trách | Test Manager / tổ chức | Test Lead / Test Manager của dự án |
Trên thực tế, test plan của dự án thường kế thừa chiến lược test của tổ chức rồi cụ thể hoá: chọn test approach phù hợp với bối cảnh (test item, đặc tính chất lượng, test level/type, SDLC, năng lực đội, yêu cầu pháp lý). Gặp thuật ngữ lạ khi đọc tài liệu, bạn tra nhanh ở thuật ngữ kiểm thử.
Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!