Test Plan
Tài liệu chốt phạm vi kiểm thử, cách test, ai làm, môi trường và dữ liệu nào, tiêu chí bắt đầu và kết thúc. Nó tồn tại để lúc gấp gáp không ai tự ý bỏ bớt phần quan trọng.
Định nghĩa
Đa số dự án vừa và nhỏ ở VN không có test plan đúng nghĩa. Có một file Excel danh sách test case, có lịch trên Jira, thế là chạy. Chuyện đó sống được cho tới ngày phải trả lời khách: dựa vào đâu các anh bảo hệ thống sẵn sàng go-live.
Test plan là bản cam kết: test tới đâu, không test cái gì, và điều kiện nào thì coi như xong.
Gồm những gì
Theo ISTQB, một test plan đầy đủ có các phần sau. Dự án nhỏ thì rút gọn, nhưng đừng bỏ hẳn phần phạm vi và tiêu chí kết thúc.
- Phạm vi: module nào test, module nào không test và vì sao.
- Cấp độ và loại kiểm thử: theo ISTQB v4 có năm cấp độ — component (quen gọi là unit), component integration, system, system integration tức SIT, và acceptance. UAT chỉ là một dạng của acceptance, bên cạnh nghiệm thu vận hành, nghiệm thu theo hợp đồng hoặc theo quy định pháp lý, alpha/beta. Ghi thêm các loại test cần chạy: hiệu năng, bảo mật, tương thích trình duyệt.
- Cách tiếp cận: thủ công hay tự động, kỹ thuật thiết kế case, mức độ ưu tiên theo rủi ro.
- Môi trường và dữ liệu: dùng môi trường nào, dữ liệu lấy từ đâu, có cần che dữ liệu thật không.
- Nhân sự và lịch: ai làm gì, bao nhiêu ngày công.
- Entry criteria: điều kiện để bắt đầu, ví dụ build đã pass smoke test, tài liệu đã chốt phiên bản, môi trường đã sẵn sàng.
- Exit criteria: điều kiện để kết thúc, ví dụ 100% case bắt buộc đã chạy, không còn defect Critical/High mở, các defect Medium còn lại có kế hoạch xử lý.
- Rủi ro và phương án dự phòng.
Entry và exit criteria — phần đáng viết nhất
Hai mục này là chỗ duy nhất trong test plan có sức nặng thật khi tranh luận. Không có exit criteria thì câu "test xong chưa" trở thành cảm tính, và người to tiếng nhất trong phòng sẽ quyết định.
| Loại tiêu chí | Viết kiểu đo được | Viết kiểu vô nghĩa |
|---|---|---|
| Entry | Build đã pass smoke test, môi trường SIT sẵn sàng, tài liệu đã chốt phiên bản | "Khi nào dev xong thì test" |
| Exit | Không còn defect Critical hoặc High đang Open, tỉ lệ pass từ 95% | "Chất lượng đã ổn định" |
| Tạm dừng | Trên 30% case fail ngay ngày đầu thì trả build | "Thấy nhiều lỗi quá thì dừng" |
Viết cho đo được. "Chất lượng ổn định" là câu vô nghĩa. "Không còn defect Critical hoặc High ở trạng thái Open, tỉ lệ case pass từ 95% trở lên, mọi case thuộc luồng thanh toán đều pass" thì đo được, và ai muốn bỏ qua sẽ phải ký tên vào chỗ bỏ qua.
Ví dụ thực tế
Cuối SIT còn bốn defect: 3 cái Medium ở module báo cáo, 1 cái ở phần tính học phí. Theo thói quen thì cả bốn được gộp chung vào một câu "lỗi nhỏ, lên trước fix sau".
Đây là dự án nâng cấp hệ thống quản lý học viên cho một trung tâm tiếng Anh 11 chi nhánh, test plan gọn hai trang. Trong hai trang đó có đúng một dòng exit criteria cứu cả đợt: "Chức năng xếp lớp và tính học phí phải pass 100% test case, các module khác cho phép còn defect mức Medium". Vì dòng đó, đội lùi go-live ba ngày để fix cái học phí. Ba ngày ấy rẻ hơn nhiều so với việc tính sai học phí cho vài trăm học viên rồi ngồi giải thích với phụ huynh.
Bản rút gọn cho team Agile
Không cần tài liệu 20 trang cho mỗi sprint. Một trang gồm 5 mục là đủ dùng: phạm vi sprint này, những gì cố ý không test, môi trường, ai test, exit criteria. Dán vào Confluence, cập nhật đầu mỗi sprint.
Phần "cố ý không test" nghe lạ nhưng nên có. Nó biến quyết định ngầm thành quyết định công khai, và khi có sự cố ở đúng vùng đó, cuộc họp sẽ bớt đi phần đổ lỗi.
BA đọc test plan để làm gì
Bạn đối chiếu phạm vi test với danh sách yêu cầu của mình. Yêu cầu nào quan trọng mà nằm ngoài phạm vi test thì lên tiếng ngay lúc đó, đừng đợi tới lúc khách phát hiện. Bạn cũng là người xác nhận dữ liệu test có phản ánh đúng thực tế nghiệp vụ không — dữ liệu bịa quá đẹp thì test xong vẫn không yên tâm.
