Review test case thế nào để KHÔNG lọt case? Quy trình chuẩn + checklist

🚀 Thiết lập trong 5 bước

Mất khoảng 10-15 phút lần đầu, sau đó chỉ việc dùng.

1. 1
   Chuẩn bị & chọn người review

   Tiêu chí vào (entry): requirement đã chốt, bộ test case + RTM (hoặc danh sách requirement) đã có. Chọn reviewer theo GÓC NHÌN — mỗi người bắt một loại lỗi khác nhau: • Peer QA: kỹ thuật + độ phủ • Dev: giả định setup/tiền điều kiện có khớp code không • BA: case có đúng cái requirement yêu cầu không • Test lead: trùng lặp, độ ưu tiên, chiến lược Chọn hình thức: peer review (nhẹ, async, 1 người soát) cho đa số; inspection (formal, có moderator + scribe, checklist + biên bản) cho module rủi ro cao (thanh toán, bảo mật). Tổ chức file để soát cho dễ: mỗi màn hình lưu một file test case riêng trong thư mục test-cases/ (vd test-cases/dang-nhap.md, test-cases/dang-ky.md). Cách này vừa lưu lại được lịch sử, vừa để Claude Code đọc và review từng file độc lập; kết quả review ghi sang thư mục review/.

   Chưa có bộ test case? Xem bài Viết test case từ user story →
2. 2
   Review theo checklist 7 nhóm

   Soát từng tiêu chí thay vì đọc cảm tính — để không phụ thuộc trí nhớ: ① Độ phủ — mỗi requirement có ≥1 case; đủ happy/negative/biên/bảo mật; có E2E nếu cần; đối chiếu RTM. ② Đúng đắn — kết quả mong đợi đúng nghiệp vụ (không bịa); dữ liệu test hợp lệ; tiền điều kiện khả thi. ③ Rõ ràng — bước cụ thể, chạy lại được; tiêu đề rõ mục tiêu, không mơ hồ. ④ Nhất quán — đúng format/cột chuẩn; quy ước ID; ưu tiên hợp lý. ⑤ Không trùng — không case trùng; mỗi case 1 mục tiêu (atomic). ⑥ Truy vết — mỗi case map tới Req ID. ⑦ Dữ liệu/Môi trường — dữ liệu đủ; nêu rõ môi trường cần. Tải bản checklist Excel (có cột Đánh giá: Đạt/Không đạt/Cần sửa) để tick khi soát:

   Tải Review Checklist (Excel) ở Kho Template QA →
3. 3
   Ghi nhận findings + thảo luận

   Mỗi vấn đề phát hiện → ghi lại (đừng sửa tại chỗ rồi quên): Case ID | Vấn đề | Nhóm checklist | Mức độ | Đề xuất sửa. Feedback phải CỤ THỂ và mang tính xây dựng ('TC-05 thiếu kết quả mong đợi cho nhánh sai mật khẩu' — không phải 'case này chưa ổn'). Vấn đề cần làm rõ nghiệp vụ → đánh dấu hỏi BA.
4. 4
   Author cập nhật + reviewer verify lại

   Author sửa bộ test case theo từng finding. Reviewer KIỂM LẠI các fix — đừng đóng finding khi chưa verify (lỗi hay quay lại). Nếu sửa phát sinh case mới, soát nhanh case mới đó luôn. Giữ nguyên format chuẩn khi sửa (mẹo: để Claude Code nhớ format — xem bài 'Claude Code nhớ quy tắc QA').
5. 5
   Chốt — tiêu chí ra (exit)

   Chỉ đánh dấu 'Approved' khi: hết finding mức Nghiêm trọng/Cao đang mở; độ phủ requirement đạt (RTM không còn dòng trống); format đúng chuẩn. Ghi lại ai duyệt + ngày. Bộ test case giờ sẵn sàng execute.

🔍 2 prompt — kèm chỗ AI hay sai cần bắt

AI sinh kết quả chỉ trong vài giây — việc của bạn là kiểm lại. Mỗi prompt kèm ví dụ kết quả và 🔍 Góc soi lỗi của Tester (chỗ AI hay sai, nên xem trước khi dùng). Bấm Copy → dán vào Claude Code / ChatGPT.

Đọc tất cả file test case trong thư mục test-cases/ (mỗi file là một màn hình). Đóng vai reviewer QA, soát TỪNG file theo checklist 7 nhóm: Độ phủ, Đúng đắn, Rõ ràng, Nhất quán, Không trùng, Truy vết, Dữ liệu/Môi trường.

Với mỗi vấn đề tìm thấy, ghi một dòng: Case ID | Màn hình (tên file) | Vấn đề | Nhóm | Mức độ | Đề xuất sửa.
Chỉ rõ: case trùng nội dung, case mơ hồ ("kiểm tra chức năng đúng"), case thiếu kết quả mong đợi, thiếu tiền điều kiện. Chỉ dựa trên nội dung file; không bịa.

Đối chiếu tài liệu requirement (các file trong thư mục requirement/, hoặc trang Confluence đã kết nối) với toàn bộ file test case trong thư mục test-cases/.

Trả về bảng: Req ID | Mô tả ngắn | Đã có case? | File / Case liên quan. Chỉ rõ requirement nào CHƯA được case nào bao phủ (lỗ hổng phủ) + đề xuất loại case nên thêm và nên đặt vào màn hình/file nào. Chỉ dựa trên nội dung tài liệu; không bịa.

Lưu kết quả ra file review/do-phu-requirement.md.