Test Plan Là Gì? Mẫu Test Plan Cơ Bản Cho Dự Án Fresher
6 tháng trước · 12 phút đọc
Test plan là gì và tại sao fresher cần biết?
Mình nhớ lần đầu đọc JD tester trên ITviec, thấy dòng "kinh nghiệm viết test plan" là tim đập nhanh hơn một nhịp. Lúc đó mình nghĩ test plan là thứ gì đó phức tạp chỉ senior mới làm được.
Thực ra không phải vậy.
Test plan (kế hoạch kiểm thử) là tài liệu mô tả: mình sẽ test cái gì, ai test, test khi nào, test bằng công cụ gì, và coi kết quả ra sao thì được coi là đạt. Hiểu đơn giản, nó như bản kế hoạch trước khi đi thi - bạn cần biết môn thi gì, ôn phần nào, thi ngày nào, đạt điểm bao nhiêu là qua.
Test plan là tài liệu định hướng, không phải văn bản hành chính khô khan
Tại sao fresher cần biết? Vì phần lớn nhà tuyển dụng yêu cầu ứng viên tester có hiểu biết cơ bản về test planning, ngay cả vị trí junior. Không cần viết hoàn hảo, nhưng cần hiểu cấu trúc và có thể điền vào mẫu có sẵn. Đó là điểm khác biệt giữa CV được gọi phỏng vấn và CV bị lướt qua.
Và thêm một điều mình muốn nói thẳng: test plan giúp chính bạn, không phải chỉ để trình cho sếp. Khi bắt đầu test mà không có kế hoạch, bạn rất dễ bỏ sót tính năng quan trọng, hoặc test xong không biết mình đã cover đủ chưa.
Cấu trúc test plan gồm những gì?
Test plan không có format cứng nhắc duy nhất - mỗi công ty có template riêng. Nhưng hầu hết đều có 6 thành phần cốt lõi này:
6 thành phần này xuất hiện trong hầu hết template test plan của các công ty
1. Scope (Phạm vi kiểm thử)
Test cái gì, và quan trọng không kém: không test cái gì. Khai báo rõ scope giúp team tránh "scope creep" - tức test lan man ra ngoài phạm vi rồi hết thời gian, tính năng quan trọng lại chưa test đủ.
Ví dụ: Dự án app đặt đồ ăn. Scope bao gồm tính năng đăng nhập, tìm kiếm món, đặt hàng, thanh toán. Scope không bao gồm: trang admin quản lý nhà hàng (team khác phụ trách).
2. Test objectives (Mục tiêu kiểm thử)
Test để làm gì? "Đảm bảo tính năng thanh toán hoạt động đúng theo yêu cầu" khác với "Đảm bảo app không crash khi mạng yếu". Mục tiêu khác nhau dẫn đến test approach khác nhau.
3. Resources (Nguồn lực)
Ai test? Dùng công cụ gì? Môi trường test là gì (staging hay production)? Phần này trả lời câu hỏi về con người, thiết bị, và tool. Fresher hay bỏ qua mục này vì nghĩ "chỉ mình tự test thôi", nhưng ghi rõ vào giúp bạn tự nhắc: cần cài thêm tool gì, cần quyền truy cập môi trường nào.
4. Schedule (Lịch trình)
Test từ ngày nào đến ngày nào. Milestone nào cần xong trước. Phần này quan trọng đặc biệt khi project có deadline cứng - bạn cần ước lượng được thời gian cần thiết để không rơi vào tình huống "hết giờ mà chưa test xong".
5. Test types (Loại kiểm thử)
Sẽ chạy những loại testing nào? Functional testing, regression testing, performance testing hay UAT (kiểm thử chấp nhận người dùng)? Không nhất thiết làm hết - chọn loại phù hợp với giai đoạn và tính chất dự án.
6. Pass/Fail criteria (Tiêu chí đạt/không đạt)
Đây là phần fresher hay bỏ sót nhất. Thế nào thì coi là test pass? Không phải cứ "chạy được" là pass. Ví dụ: "Pass khi 100% test case critical không có bug severity 1-2; fail nếu có bug critical chưa fix."
Thấy nhiều không? Mình hứa: mẫu ở phần sau chỉ giữ lại thứ bạn thực sự cần cho dự án nhỏ.
Mẫu test plan đơn giản cho fresher (tiếng Việt)
Dưới đây là mẫu mình thiết kế riêng cho dự án nhỏ, phù hợp khi bạn đang học hoặc mới đi làm. Không quá 2 trang A4, đủ để thể hiện bạn hiểu quy trình.
Tải file mẫu về điền luôn: Tải mẫu test plan tiếng Việt (.html)
Mẫu này phù hợp cho dự án 1-3 tester, thời gian test 1-2 tuần
Cấu trúc mẫu như sau:
# TEST PLAN - [Tên dự án]
Phiên bản: 1.0 | Ngày: DD/MM/YYYY | Người viết: [Tên bạn]
## 1. PHẠM VI KIỂM THỬ (SCOPE)
Test bao gồm:
- [Tính năng 1]
- [Tính năng 2]
Không bao gồm:
- [Tính năng nằm ngoài phạm vi]
## 2. MỤC TIÊU
Đảm bảo [mô tả mục tiêu cụ thể] hoạt động đúng theo tài liệu yêu cầu.
## 3. NGUỒN LỰC
- Tester: [Tên]
- Môi trường: [Staging/UAT - URL cụ thể]
- Công cụ: Jira (quản lý bug), Excel (test case), Chrome DevTools
- Dữ liệu test: [Mô tả data test dùng]
## 4. LỊCH TRÌNH
| Hoạt động | Bắt đầu | Kết thúc |
|-------------------|------------|------------|
| Viết test case | DD/MM/YYYY | DD/MM/YYYY |
| Thực thi test | DD/MM/YYYY | DD/MM/YYYY |
| Regression test | DD/MM/YYYY | DD/MM/YYYY |
| Tổng hợp báo cáo | DD/MM/YYYY | DD/MM/YYYY |
## 5. LOẠI KIỂM THỬ
- Functional testing: kiểm tra tính năng đúng yêu cầu
- Regression testing: kiểm tra tính năng cũ sau khi fix bug
- Smoke testing: kiểm tra nhanh trước khi test đầy đủ
## 6. TIÊU CHÍ PASS/FAIL
Pass:
- Tất cả test case đã thực thi
- Không còn bug severity 1 (critical) hoặc severity 2 (high) chưa fix
- Bug severity 3 (medium) còn lại đã được team xác nhận chấp nhận
Fail:
- Còn bug critical chưa fix
- Tính năng trong scope chưa được test đủ
Một lưu ý nhỏ: đừng cố điền cho "đẹp" nếu bạn chưa có thông tin đầy đủ. Ghi "TBD" (to be determined - sẽ cập nhật sau) vào những chỗ chưa xác định được còn hơn là bịa số liệu. Test plan là tài liệu sống - được phép cập nhật theo tiến độ dự án.
Cách viết test plan cho dự án nhỏ khi đi xin việc
Bạn đang tự học, chưa có kinh nghiệm thực tế? Không sao. Mình hướng dẫn cách viết test plan cho dự án cá nhân - thứ bạn có thể đưa vào portfolio khi ứng tuyển trên TopDev hay ITviec.
Chọn dự án phù hợp
Không cần app phức tạp. Một trang web thương mại điện tử đơn giản (như template Shopee từ khóa HTML CSS), app to-do list, hoặc form đăng ký đều đủ để viết test plan có giá trị. Mấu chốt là chọn thứ có đủ user flow để test: đăng nhập, thao tác chính, xử lý lỗi.
Dự án nhỏ mà test đủ còn giá trị hơn dự án lớn test qua loa
Viết scope trước, viết test case sau
Sai lầm phổ biến của fresher: nhảy vào viết test case ngay mà không xác định scope. Kết quả là viết mãi không hết, hoặc bỏ sót phần quan trọng vì không nhìn được toàn cảnh. Scope phải xong trước - đó là lý do test plan tồn tại.
Ước lượng thời gian thực tế
Phần schedule hay bị điền sai vì ước lượng quá lạc quan. Một test case mất trung bình 5-15 phút để thực thi (tùy độ phức tạp). Nếu bạn có 50 test case, tính ra ít nhất 4-12 tiếng thực thi - chưa kể thời gian viết bug report, retest, và regression.
| Hoạt động | Ước tính thời gian |
|---|---|
| Viết 1 test case | 10-20 phút |
| Thực thi 1 test case | 5-15 phút |
| Viết 1 bug report | 10-15 phút |
| Retest 1 bug | 5-10 phút |
Cộng thêm 20% buffer cho việc phát sinh ngoài dự kiến. Đây là con số mình học được sau nhiều lần "tưởng kịp nhưng không kịp".
Tiêu chí pass/fail: cụ thể thay vì chung chung
"Không có bug" là tiêu chí không thực tế. Hầu hết phần mềm release đều có bug - vấn đề là bug đó có nghiêm trọng không. Phân loại severity (mức độ nghiêm trọng) ngay từ đầu: critical, high, medium, low. Tiêu chí pass nên là "không có bug critical/high chưa giải quyết", không phải "zero bug".
Khóa Kiểm thử phần mềm có phần thực hành viết test plan cho dự án mẫu - nếu bạn muốn có feedback từ người có kinh nghiệm thay vì tự mò.
Những lỗi fresher hay mắc khi viết test plan
Mình từng review test plan của học viên và thấy 4 lỗi này lặp đi lặp lại. Biết trước để tránh.
Lỗi 1: Scope quá rộng hoặc quá hẹp
Scope quá rộng: "Test toàn bộ hệ thống". Câu này không có nghĩa gì vì không ai biết "toàn bộ" là đến đâu. Scope quá hẹp: chỉ liệt kê 1-2 tính năng nhỏ trong khi tính năng quan trọng nhất lại không có. Viết scope bằng cách liệt kê từng module hoặc user story cụ thể.
Lỗi 2: Bỏ trống phần "không bao gồm"
Khai báo out-of-scope quan trọng không kém in-scope. Nếu không rõ, khi có bug ở vùng chưa test, stakeholder sẽ hỏi "sao không test cái này?" - và bạn không có gì để trả lời.
Ghi rõ những gì không test còn quan trọng hơn ghi những gì test
Lỗi 3: Schedule không tính đến dependency
Bạn không thể chạy regression testing trước khi dev fix bug xong. Bạn không thể viết test case trước khi có tài liệu yêu cầu. Schedule phải phản ánh đúng thứ tự công việc - cái gì cần xong trước thì đặt trước.
Lỗi 4: Không cập nhật test plan trong quá trình
Dự án thay đổi - tính năng thêm bớt, deadline dời, resource thay đổi. Test plan phải đi cùng với những thay đổi đó. Fresher hay viết test plan lúc đầu rồi "quên" cập nhật, kết quả là tài liệu không phản ánh thực tế. Ghi version number (1.0, 1.1, 1.2...) và ngày cập nhật vào đầu tài liệu để track được thay đổi.
Nếu thấy những lỗi này quen quen thì bình thường - mình cũng mắc hết khi mới viết test plan đầu tiên. Quan trọng là biết để lần sau không mắc lại.
Bắt đầu viết test plan đầu tiên của bạn
Testing không khó. Cái khó là giữ thói quen lên kế hoạch trước khi làm - đặc biệt khi deadline gấp và bạn muốn nhảy thẳng vào test cho nhanh.
Nhưng mình nói thật: test không có plan giống lái xe không có bản đồ. Bạn sẽ đến nơi, nhưng mất nhiều thời gian hơn và dễ đi lạc.
Để bắt đầu ngay:
- Tải mẫu test plan ở phần trên về
- Chọn 1 dự án bạn đang test hoặc dự án cá nhân
- Điền lần lượt từ phần 1 (Scope) trước - đừng nhảy lung tung
- Nếu có phần chưa biết điền gì: ghi "TBD" rồi tiếp tục
- Review lại sau khi điền xong, hỏi: "Người khác đọc vào có hiểu mình sẽ test gì không?"
Bắt đầu từ bước 1, điền dần - không cần hoàn hảo ngay lần đầu
Test plan đầu tiên của bạn sẽ không hoàn hảo. Test plan đầu tiên của mình cũng vậy. Nhưng có một tài liệu không hoàn hảo còn tốt hơn không có gì - vì từ đó bạn biết cần cải thiện chỗ nào.
25 hay 30 tuổi, trái ngành hay cùng ngành, chưa có kinh nghiệm thực tế - không có gì trong số đó cản bạn viết được test plan tử tế cho dự án nhỏ. Mình từng thấy bạn 33 tuổi chuyển từ kế toán sang, test plan đầu tiên còn sơ sài hơn bạn nghĩ, nhưng sau 3 dự án thực hành thì viết ra xịn hơn nhiều fresher CNTT.
Comment bên dưới nếu bạn đang mắc kẹt ở phần nào, mình trả lời từng bạn. Chúc thành công!