Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn được giao kiểm thử một dự án lớn: một ứng dụng ngân hàng số với hàng trăm màn hình, ba nền tảng (web, iOS, Android), tích hợp năm cổng thanh toán và thời hạn go-live chỉ còn sáu tuần. Sếp hỏi bạn: "Chúng ta sẽ test cái gì? Ai làm phần nào? Bao giờ xong? Cần bao nhiêu người? Nếu không kịp thì cắt cái gì?"
Nếu bạn không có câu trả lời rõ ràng cho những câu hỏi đó, dự án của bạn đang lái xe trong sương mù. Và Test Plan chính là tấm bản đồ giúp bạn nhìn xuyên qua sương mù ấy.
Test Plan là tài liệu "master" mô tả một cách có hệ thống: ai test cái gì, khi nào, ở đâu, bằng công cụ gì, theo tiêu chí nào, và điều gì có thể làm hỏng kế hoạch. Nó không phải là danh sách test case (đó là việc của Bài 24), cũng không phải quy trình báo lỗi (Bài 27). Test Plan đứng cao hơn — nó là chiến lược và cam kết của cả đội kiểm thử với toàn bộ dự án.
Chuẩn IEEE 829 (tên đầy đủ: IEEE Standard for Software and System Test Documentation, phiên bản gốc 1998, cập nhật 2008) đưa ra một khung xương chuẩn hóa để viết Test Plan. Dù ngày nay nhiều đội Agile viết Test Plan gọn nhẹ hơn, khung IEEE 829 vẫn là "ngôn ngữ chung" mà mọi QA chuyên nghiệp cần nắm — nó là nền tảng cho câu hỏi phỏng vấn ISTQB, cho hồ sơ đấu thầu outsourcing, và cho những dự án cần audit (ngân hàng, y tế, viễn thông). Học được khung này, bạn sẽ biết cách suy nghĩ có cấu trúc kể cả khi viết một test plan một trang cho sprint hai tuần.
Khái niệm cốt lõi
Test Plan là gì và không là gì
Test Plan trả lời câu hỏi "HOW và WHAT ở tầm dự án", không đi vào chi tiết từng bước bấm nút. Một cách ví von: nếu test case là công thức nấu một món ăn cụ thể, thì Test Plan là thực đơn của cả nhà hàng cộng với lịch phân công đầu bếp, danh sách nguyên liệu, và phương án dự phòng khi bếp trưởng nghỉ ốm.
Test Plan phục vụ ba nhóm người đọc:
- Đội QA — biết mình phải làm gì, phạm vi đến đâu.
- Quản lý dự án (PM) và khách hàng — biết cần bao nhiêu thời gian, nhân lực, và rủi ro nằm ở đâu.
- Đội phát triển và các bên liên quan — biết QA kỳ vọng gì ở môi trường, dữ liệu, và điều kiện bàn giao.
16 mục chuẩn của IEEE 829
Chuẩn IEEE 829 định nghĩa Test Plan gồm 16 mục. Bạn không nhất thiết dùng hết mọi mục cho mọi dự án, nhưng hãy hiểu vai trò của từng mục:
- Test plan identifier — Mã định danh duy nhất và số phiên bản. Ví dụ:
TP-VCB-MOBILE-v1.3. Nghe có vẻ hình thức, nhưng khi dự án có 20 tài liệu lưu hành và ai cũng sửa, mã định danh + version giúp bạn biết mình đang bàn về bản nào. Luôn kèm bảng lịch sử thay đổi (change log).
- Introduction — Giới thiệu: mục tiêu kiểm thử, phạm vi tổng quan, tham chiếu tới các tài liệu khác (SRS, tài liệu thiết kế, hợp đồng). Cho người đọc bối cảnh trong 30 giây.
- Test items — Cái gì được đem ra test: tên module/thành phần, phiên bản build, cấu hình. Ví dụ: "API thanh toán v2.4.1, app Android build 305, web portal nhánh
release/6.0".
- Features to be tested — Tính năng có test. Liệt kê rõ ràng những chức năng nằm trong phạm vi, theo góc nhìn người dùng. Ví dụ: đăng nhập, chuyển khoản nội bộ, nạp tiền qua MoMo, lịch sử giao dịch.
- Features NOT to be tested — Tính năng KHÔNG test và lý do. Đây là mục hay bị bỏ quên nhưng cực kỳ quan trọng để bảo vệ bạn về sau. Ví dụ: "Chức năng vay tiêu dùng — không test trong đợt này vì chưa tích hợp, sẽ nằm trong release 6.1." Ghi rõ để không ai đổ lỗi "sao QA không test cái đó".
- Approach (chiến lược) — Trái tim của Test Plan. Mô tả cách tiếp cận: các cấp độ test (unit/integration/system/acceptance), loại test (chức năng, hiệu năng, bảo mật), kỹ thuật thiết kế (EP, BVA, decision table — nhắc đến chứ không dạy lại), mức độ tự động hóa, và công cụ. Đây là nơi bạn thể hiện tư duy chuyên môn.
- Item pass/fail criteria — Tiêu chí một test item được coi là "đạt". Ví dụ: "Test item đạt khi 100% test case Critical/High pass và không còn bug Blocker/Critical mở."
- Suspension criteria & resumption requirements — Khi nào tạm dừng test và điều kiện để tiếp tục. Ví dụ: "Tạm dừng nếu build không cài được, hoặc >30% test case smoke fail. Tiếp tục khi dev giao build sửa và smoke test pass lại." Mục này cứu bạn khỏi việc cắm đầu test trên một build hỏng, lãng phí thời gian.
- Test deliverables — Các sản phẩm bàn giao: bản thân Test Plan, bộ test case, test data, báo cáo thực thi, báo cáo tổng kết (test summary), log lỗi.
- Testing tasks — Các đầu việc và phụ thuộc giữa chúng. Ví dụ: viết test case phải xong trước khi thực thi; chuẩn bị dữ liệu phải xong trước ngày X.
- Environmental needs — Nhu cầu môi trường: phần cứng, phần mềm, mạng, dữ liệu, quyền truy cập, thiết bị thật. Ví dụ: "Cần 5 điện thoại Android thật (Samsung A-series, Xiaomi Redmi), tài khoản sandbox VNPay, môi trường staging tách biệt production."
- Responsibilities — Ai chịu trách nhiệm gì. Thường trình bày bằng ma trận RACI (Responsible/Accountable/Consulted/Informed).
- Staffing and training needs — Số lượng, kỹ năng nhân sự cần có, và nhu cầu đào tạo. Ví dụ: "Cần 1 tester biết Appium cho automation mobile; nếu thiếu, đào tạo 3 ngày."
- Schedule — Lịch trình: các mốc (milestone), thời gian cho từng giai đoạn, gắn với lịch tổng của dự án.
- Risks and contingencies — Rủi ro và phương án đối phó. Ví dụ: "Rủi ro: cổng thanh toán sandbox không ổn định → dự phòng: mock cổng thanh toán để test luồng nghiệp vụ song song."
- Approvals — Chữ ký phê duyệt của các bên: Test Lead, PM, khách hàng. Biến Test Plan từ "ý kiến của QA" thành "cam kết được đồng thuận".
Master Test Plan vs Level Test Plan
IEEE 829 phân biệt hai cấp: Master Test Plan (MTP) bao trùm toàn bộ dự án và các cấp độ test, còn Level Test Plan (LTP) đi sâu vào từng cấp (ví dụ System Test Plan, Acceptance Test Plan riêng). Dự án nhỏ chỉ cần một Test Plan; dự án lớn nhiều đội thì tách MTP + nhiều LTP để mỗi đội tự quản phần của mình.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số Timo: mục "Features NOT to be tested" cứu cả đội
Một đội QA outsourced (giả định, 6 người) nhận kiểm thử bản nâng cấp app ngân hàng số cho ngân hàng đối tác. Bản Test Plan v1.0 liệt kê rất đầy đủ tính năng có test, nhưng bỏ trống mục "Features NOT to be tested".
Đến ngày demo cho khách hàng, một lãnh đạo hỏi: "Tính năng chuyển tiền quốc tế đã test chưa?" Cả đội tái mặt — tính năng đó chưa nằm trong phạm vi vì backend chưa xong, nhưng vì không ghi rõ, khách hàng cho rằng QA đã "quên test", uy tín đội bị ảnh hưởng và phải giải trình mất hai ngày.
Ở release sau, Test Lead bổ sung mục 5 rõ ràng: "Chuyển tiền quốc tế — KHÔNG test đợt này, lý do: dịch vụ SWIFT chưa tích hợp, dự kiến release Q3." Kèm chữ ký phê duyệt của cả PM và khách hàng ở mục Approvals.
Bài học: Test Plan không chỉ nói bạn làm gì, mà còn bảo vệ bạn bằng cách nói rõ bạn không làm gì và ai đã đồng ý. Một dòng "out of scope" được ký duyệt đáng giá hơn mười lời giải thích sau sự cố.
Ví dụ 2 — Sàn TMĐT mùa sale 11.11: mục "Suspension criteria" tiết kiệm 3 ngày công
Một đội QA của sàn thương mại điện tử (giả định quy mô Tiki/Sendo) chuẩn bị cho đợt sale lớn. Test Plan có mục Suspension criteria: "Tạm dừng system test nếu smoke test đầu ngày có >20% case fail, hoặc nếu module giỏ hàng không thêm được sản phẩm."
Sáng thứ Hai, dev deploy build mới. Tester chạy smoke 15 phút, phát hiện giỏ hàng lỗi hoàn toàn — thêm sản phẩm nào cũng báo lỗi 500. Theo đúng suspension criteria, Test Lead lập tức dừng toàn đội, không cho ai chạy test tiếp, và trả build về cho dev với một bug report duy nhất, rõ ràng.
Nếu không có tiêu chí này, 4 tester sẽ mỗi người tự chạy test case của mình, tạo ra hàng chục bug report trùng lặp ("không thanh toán được", "không xem được giỏ", "không áp mã giảm giá" — tất cả đều do một nguyên nhân gốc), tốn cả ngày rồi mới nhận ra. Ước tính đội tiết kiệm được khoảng 3 ngày công và tránh làm nhiễu bảng bug.
Bài học: Tiêu chí tạm dừng/tiếp tục biến phản ứng cảm tính ("build này hình như hỏng, test tiếp không nhỉ?") thành quyết định có kỷ luật, dựa trên ngưỡng đã thống nhất trước.
Ví dụ 3 — Startup fintech VN: Test Plan một trang cho Agile
Không phải lúc nào cũng cần bản Test Plan 40 trang. Một startup fintech ở TP.HCM (giả định, đội 3 QA, chạy sprint 2 tuần) áp dụng IEEE 829 theo tinh thần "gọn nhẹ": họ giữ một Test Plan sống (living document) trên Confluence chỉ khoảng một trang rưỡi, nhưng vẫn giữ đúng tinh thần các mục quan trọng.
Cụ thể họ giữ: phạm vi sprint (features có/không test), approach (test tay + 20% automation API bằng Postman), tiêu chí Definition of Done, môi trường (staging + sandbox VNPay), rủi ro chính (sandbox VNPay hay sập cuối tháng → mock lại). Họ bỏ các mục nặng hình thức như staffing/training vì đội cố định, và gộp responsibilities vào một dòng.
Kết quả: người mới vào đội đọc một trang là hiểu ngay "chúng ta test gì và test thế nào", còn khi khách hàng doanh nghiệp yêu cầu bằng chứng quy trình để ký hợp đồng, đội chỉ cần mở rộng bản này lên đủ 16 mục IEEE 829 trong một buổi.
Bài học: IEEE 829 là khung tư duy, không phải chiếc áo bó buộc. Hãy điều chỉnh độ chi tiết theo bối cảnh — nhưng nếu cắt mục nào, hãy cắt một cách có ý thức, biết mình đang đánh đổi gì.
Hướng dẫn từng bước
Đây là quy trình thực tế để viết một Test Plan từ con số 0:
Bước 1 — Thu thập đầu vào. Đọc tài liệu yêu cầu (SRS/user story), tài liệu thiết kế, hợp đồng, và trao đổi với PM về lịch và ngân sách. Bạn không thể lập kế hoạch cho thứ mình chưa hiểu.
Bước 2 — Xác định phạm vi (scope). Viết mục Features to be tested và Features NOT to be tested trước tiên. Ranh giới rõ ràng là 50% giá trị của Test Plan. Với mỗi tính năng loại ra, ghi kèm lý do.
Bước 3 — Chọn cách tiếp cận (approach). Quyết định cấp độ test, loại test, kỹ thuật thiết kế, mức tự động hóa và công cụ. Cân nhắc rủi ro: phần nào quan trọng/dễ hỏng thì đầu tư test nhiều hơn.
Bước 4 — Định nghĩa tiêu chí. Viết rõ pass/fail criteria, suspension/resumption criteria, và entry/exit criteria (điều kiện bắt đầu và kết thúc một giai đoạn test). Dùng số đo lượng hóa được, tránh chữ chung chung như "test kỹ".
Bước 5 — Lập kế hoạch nguồn lực và môi trường. Xác định cần bao nhiêu người, kỹ năng gì, thiết bị/môi trường/dữ liệu nào. Ghi rõ ai chịu trách nhiệm cung cấp (thường môi trường là việc của DevOps, không phải QA tự lo).
Bước 6 — Lên lịch và mốc. Ước lượng thời gian cho từng giai đoạn (viết case, thực thi, hồi quy), gắn với lịch tổng dự án, chừa buffer cho vòng sửa lỗi.
Bước 7 — Phân tích rủi ro. Với mỗi rủi ro, ghi tác động, xác suất và phương án dự phòng. Đây là mục thể hiện sự trưởng thành của một Test Lead.
Bước 8 — Rà soát và phê duyệt. Cho PM, dev lead, và khách hàng đọc, phản biện, rồi ký duyệt. Test Plan chưa được duyệt chỉ là bản nháp.
Bước 9 — Coi nó là tài liệu sống. Cập nhật khi phạm vi đổi, tăng số phiên bản, ghi vào change log. Một Test Plan không bao giờ được cập nhật sẽ nhanh chóng trở thành nói dối.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết cho có rồi cất tủ. Nhiều đội viết Test Plan chỉ để "đủ thủ tục", viết xong không ai đọc lại. Test Plan phải là công cụ ra quyết định hàng ngày, không phải vật trang trí.
Lỗi 2 — Bỏ mục "Features NOT to be tested". Như ví dụ Timo ở trên: không ghi phạm vi loại trừ là tự đặt bẫy cho chính mình.
Lỗi 3 — Tiêu chí mơ hồ. "Test khi nào thấy ổn thì thôi" không phải tiêu chí. Hãy lượng hóa: "0 bug Blocker/Critical mở, ≥95% test case High pass".
Lỗi 4 — Nhầm Test Plan với Test Strategy hoặc Test Case. Test Strategy là tài liệu tổ chức, cấp cao, ít thay đổi (thường chung cho nhiều dự án); Test Plan cụ thể cho một dự án/release; Test Case là chi tiết từng bước. Đừng nhồi hàng trăm test case vào Test Plan.
Lỗi 5 — Quên phần rủi ro. Test Plan không có mục rủi ro giống như đi biển không xem dự báo thời tiết.
Mẹo 1 — Dùng template có sẵn. Đừng viết từ trang giấy trắng. Giữ một template chuẩn 16 mục và cắt bớt tùy dự án.
Mẹo 2 — Viết mục Approach cuối cùng nhưng nghĩ về nó đầu tiên. Chiến lược quyết định mọi mục khác, nên hãy hình dung nó sớm, rồi chắt lọc lại khi đã có đủ thông tin.
Mẹo 3 — Với Agile, giữ Test Plan là "living document" một trang trên wiki, cập nhật mỗi sprint thay vì viết bản đồ sộ đầu dự án rồi bỏ mặc.
Mẹo 4 — Luôn có version và change log. Một dòng "v1.2 — thêm tính năng nạp ZaloPay vào scope, 27/06/2026" giúp cả đội biết chuyện gì đã thay đổi.
Bài tập thực hành
Bài 1 — Xác định phạm vi. Cho dự án: một app đặt lịch khám bệnh cho phòng khám ở Hà Nội, release đầu tiên gồm đăng ký tài khoản, đặt lịch, thanh toán qua MoMo. Chức năng nhắc lịch qua SMS và tư vấn video chưa xây xong. Hãy viết mục Features to be tested và Features NOT to be tested (kèm lý do) cho Test Plan.
Bài 2 — Viết tiêu chí. Viết pass/fail criteria và suspension criteria cho luồng thanh toán MoMo của app trên. Nhớ lượng hóa bằng con số cụ thể.
Bài 3 — Phân tích rủi ro. Liệt kê 3 rủi ro cho dự án trên (gợi ý: sandbox MoMo, thiết bị thật, deadline). Với mỗi rủi ro, ghi tác động và một phương án dự phòng.
Bài 4 — Rút gọn. Lấy khung 16 mục IEEE 829 và quyết định: nếu bạn chỉ được viết Test Plan một trang cho sprint 2 tuần, bạn giữ lại những mục nào, gộp/bỏ mục nào, và tại sao?
Bài 5 — Phản biện. Tìm một Test Plan mẫu trên mạng (từ khóa "IEEE 829 test plan template"), đọc và chỉ ra 2 mục mà bạn thấy được viết mơ hồ, rồi viết lại cho rõ ràng, đo lường được.
Tóm tắt
- Test Plan là tài liệu master trả lời "ai test gì, khi nào, ở đâu, thế nào, theo tiêu chí nào, rủi ro gì" — ở tầm dự án, không phải chi tiết từng bước.
- Chuẩn IEEE 829 đưa ra khung 16 mục: từ mã định danh, phạm vi có/không test, cách tiếp cận, tiêu chí pass/fail và suspension, đến nguồn lực, lịch trình, rủi ro và phê duyệt.
- Ba mục thường bị coi nhẹ nhưng cứu bạn nhiều nhất: Features NOT to be tested, Suspension criteria, và Risks & contingencies.
- IEEE 829 là khung tư duy, không phải xiềng xích: hãy điều chỉnh độ chi tiết theo bối cảnh — Agile thì gọn nhẹ, dự án audit/ngân hàng thì đầy đủ — nhưng cắt gì cũng phải cắt một cách có ý thức.
- Test Plan tốt là tài liệu sống: có version, có change log, được phê duyệt, và được dùng để ra quyết định mỗi ngày — chứ không phải viết xong rồi cất tủ.