Đây là bài quan trọng nhất trong cả module, vì mọi kỹ thuật ở các bài trước (trích xuất scenario, cấu trúc context, EP/BVA/heuristic, tổ chức suite) đều vô nghĩa nếu bạn không có khả năng review output AI một cách có hệ thống. AI sinh test case nhanh — nhưng nhanh không đồng nghĩa với đúng, và nếu bạn import case sai vào suite chính thức, nó sẽ gây hại lâu dài hơn cả việc không có test case (vì tạo cảm giác an toàn giả). Bài này liệt kê các lỗi phổ biến nhất, xây checklist review, kỹ thuật đối chiếu ngược requirement, và cách biến review thành vòng lặp cải tiến prompt.
Những Lỗi Phổ Biến Nhất Trong Test Case do AI Tạo Ra Là Gì?
Biết trước các lỗi điển hình giúp bạn review nhanh hơn nhiều so với đọc từng case mà không có định hướng — bạn biết chính xác chỗ nào cần nhìn kỹ.
Lỗi Phổ Biến 1: Đánh Tráo Kết Quả Quan Sát Được (Observable-Result Substitution)
Đây là lỗi khi AI viết expected result là một trạng thái nội bộ mà tester không thể quan sát trực tiếp (ví dụ "dữ liệu được lưu đúng vào database"), thay vì một dấu hiệu quan sát được từ bên ngoài (ví dụ "trang hiển thị thông báo đã lưu, refresh lại vẫn thấy dữ liệu mới"). Test case với expected result không quan sát được là test case không thể thực thi được bởi manual tester — họ không có quyền truy cập DB để verify trực tiếp.
Lỗi Phổ Biến 2: Mơ Hồ Về Precondition (Precondition Ambiguity)
AI thường viết precondition dạng chung ("user đã đăng nhập") mà thiếu chi tiết quyết định kết quả test (đăng nhập với vai trò gì, tài khoản có dữ liệu gì trước đó). Hai tester khác nhau thực hiện cùng một test case với precondition mơ hồ có thể chuẩn bị dữ liệu khác nhau và ra kết quả khác nhau — làm test case không còn tính tái lập (reproducible).
Lỗi Phổ Biến 3: Lạm Phát Happy-Path (Happy-Path Inflation)
Khi bạn yêu cầu AI generate "nhiều test case", nó có xu hướng đạt số lượng bằng cách nhân bản happy-path theo nhiều biến thể nhỏ không có giá trị phân biệt thật (ví dụ 5 case chỉ khác nhau ở tên hiển thị khác nhau nhưng cùng logic), thay vì đầu tư vào negative path/edge case khó nghĩ hơn. Dấu hiệu nhận biết: số lượng case positive gấp nhiều lần negative+edge trong khi requirement không hề đơn giản đến mức đó.
Lỗi Phổ Biến 4: Negative Path Hời Hợt (Shallow Negative Paths)
AI thường chỉ tạo negative path ở mức "để trống field required" — bỏ qua các negative path sâu hơn như vi phạm business rule, xung đột trạng thái, lỗi phụ thuộc bên ngoài (đã nói ở bài 1). Nếu toàn bộ negative path trong suite chỉ xoay quanh "field rỗng/sai format", đó là dấu hiệu rõ của lỗi này.
Lỗi Phổ Biến 5: Thiếu Test Chuyển Trạng Thái (Missing State-Transition Tests)
Với feature có trạng thái (đơn hàng, tài khoản, bài viết...), AI thường quên test các chuyển trạng thái không hợp lệ (ví dụ hủy đơn đã giao) vì requirement chỉ mô tả chuyển trạng thái hợp lệ một cách rõ ràng, còn chuyển trạng thái không hợp lệ là điều "ngầm hiểu" mà AI không tự suy ra nếu không được nhắc (xem lại kỹ thuật State Transition Testing ở bài 3).
Lỗi Phổ Biến 6: Bước Không Thể Test Được (Untestable Steps)
Bước hành động mô tả một hành vi không thể thực hiện được trên UI thật (ví dụ "gửi request với header bị hỏng" khi test case ghi rõ là manual test qua UI, không phải qua Postman) — dấu hiệu AI trộn lẫn ngữ cảnh test tự động và test thủ công mà không phân biệt rõ trong prompt ban đầu.
Mẹo: Khi review một batch case lớn, quét nhanh riêng cột "Expected Result" trước khi đọc từng case chi tiết — nếu thấy cụm từ như "lưu đúng vào database" hay "xử lý thành công" lặp lại nhiều lần, đó là dấu hiệu rõ nhất của lỗi Observable-Result Substitution, và bạn phát hiện được nó nhanh hơn nhiều so với đọc tuần tự từng case.
Một Checklist Review Cho Test Case do AI Tạo Nên Có Gì?
Checklist Review Test Case do AI Tạo
Danh sách kiểm tra thực dụng, áp cho từng test case trước khi approve:
- [ ] Expected result là dấu hiệu quan sát được từ bên ngoài (UI, thông báo, trạng thái hiển thị), không phải trạng thái nội bộ hệ thống.
- [ ] Precondition đủ cụ thể để 2 tester khác nhau chuẩn bị đúng cùng một trạng thái dữ liệu.
- [ ] Mỗi step chỉ chứa một hành động duy nhất.
- [ ] Negative path/edge case có tỉ lệ hợp lý so với positive path (không bị lạm phát 1 chiều).
- [ ] Test case liên kết đúng với AC/requirement cụ thể (không bị "N/A" mà không giải thích).
- [ ] Không có bước hành động nào không thể thực hiện qua kênh test đã chỉ định (UI/manual vs API/automation).
- [ ] Từ vựng/format nhất quán với chuẩn team (đã nói ở bài 2).
Mẹo: Áp checklist này theo thứ tự cố định, từng dòng, cho toàn bộ batch test case cùng lúc (không nhảy cóc giữa các dòng) — review theo "cột" (một tiêu chí cho tất cả case) thường phát hiện lỗi có hệ thống (ví dụ toàn bộ batch bị lỗi precondition) nhanh hơn review theo "hàng" (từng case một, đủ mọi tiêu chí).
Dùng AI Hỗ Trợ Việc Review
Bạn có thể để AI tự áp checklist này trước, như một bước lọc sơ bộ, để tập trung thời gian con người vào các case bị flag:
Apply this review checklist to every test case below. For each
test case, output PASS or FAIL per checklist item, with a one-line
reason for any FAIL. Do not skip any item even if the test case
looks fine overall — check every line explicitly.
CHECKLIST:
[paste checklist above]
TEST CASES:
[paste suite]
Điểm quan trọng: yêu cầu AI xuất kết quả theo từng item riêng, không phải một câu tổng kết "case này tốt" — output tổng kết dễ bị AI đơn giản hóa và bỏ sót vấn đề nhỏ.
Ưu Tiên Công Sức Review
Không phải mọi test case đáng được review kỹ như nhau. Ưu tiên theo thứ tự: (1) case liên quan tới luồng thanh toán/dữ liệu nhạy cảm/bảo mật; (2) case negative path và edge case (vì đây là nơi AI dễ sai nhất theo các lỗi phổ biến ở trên); (3) case đã được đánh dấu "Low confidence" từ bước impact analysis (bài 4); (4) case positive path đơn giản — có thể review lướt nhanh hơn.
Làm Thế Nào Để Đối Chiếu Ngược Test Case với Requirement và AC?
Review từng case riêng lẻ không đủ để phát hiện thiếu sót ở cấp độ tổng thể — cần một bước đối chiếu hai chiều giữa toàn bộ requirement và toàn bộ test suite.
Traceability Xuôi: Requirement → Test Case
Với mỗi AC, hỏi: có ít nhất một test case verify nó không? Đây là hướng traceability quen thuộc nhất, nhưng dễ làm hời hợt nếu chỉ kiểm tra "có case nào chứa từ khóa của AC" — cần kiểm tra case đó thực sự verify đúng nội dung AC, không chỉ liên quan chung chung.
For each AC below, find the test case(s) that genuinely verify it
(not just mention related keywords). If a test case only partially
verifies the AC (e.g., covers the positive condition but not the
negative condition implied), note it as PARTIAL, not FULL.
Traceability Ngược: Test Case → Requirement
Chiều ngược lại quan trọng không kém: mỗi test case phải trỏ về một requirement/AC hợp lệ. Test case không trỏ về đâu cả ("test case mồ côi" - orphan test case) có thể là case exploratory hợp lệ, hoặc có thể là case dư thừa/lỗi thời còn sót lại từ requirement đã đổi.
For each test case, verify it maps to a currently valid AC. Flag
any test case that either (a) maps to no AC at all, or (b) maps to
an AC that no longer matches current requirement wording.
Phân Tích Gap Qua Coverage Report của AI
Kết hợp cả hai chiều truy vết vào một báo cáo gap tổng hợp, có cấu trúc rõ để dùng làm căn cứ hành động (không chỉ để đọc):
Generate a coverage gap report with these sections:
COVERAGE SUMMARY, CRITICAL COVERAGE GAPS (requirements with no
coverage), PARTIAL COVERAGE GAPS (requirements covered by only
positive path tests), UNTRACEABLE TEST CASES (no valid requirement
link), RECOMMENDED NEW TEST CASES (to close gaps).
Coverage Summary
Tổng số AC, tổng số test case, tỉ lệ AC có ít nhất 1 case, tỉ lệ AC có đủ cả positive/negative/edge — đọc phần này đầu tiên để có cái nhìn tổng quan trước khi đi vào chi tiết từng gap.
Critical Coverage Gaps (requirements with no coverage)
Đây là phần ưu tiên xử lý cao nhất — AC hoàn toàn không có test case nào verify là rủi ro release lớn nhất, cần được lấp trước khi merge/release, không được để lại "làm sau".
Partial Coverage Gaps (requirements covered by only positive path tests)
Phần này cho biết AC nào chỉ được test ở happy-path — đây chính là hệ quả trực tiếp của lỗi "Happy-Path Inflation" nói ở đầu bài; xử lý bằng cách bổ sung negative/edge case cho đúng những AC bị liệt ở đây.
Untraceable Test Cases (no valid requirement link)
Phần này giúp phát hiện case dư thừa/lỗi thời hoặc case exploratory chưa được gắn nhãn đúng — đối chiếu với kỹ thuật loại bỏ case lỗi thời đã nói ở bài 4 để xử lý.
Recommended New Test Cases (to close gaps)
Đây là output hành động cụ thể nhất — danh sách case đề xuất mới, sẵn sàng đưa qua bước generate chi tiết (dùng prompt ở bài 1) rồi review lại theo checklist trước khi thêm vào suite.
Xử Lý AC Mơ Hồ Khi Đối Chiếu
Đôi khi việc đối chiếu phát hiện ra AC bản thân nó mơ hồ, không phải test case sai. Trong trường hợp này, đừng để AI "đoán" cách diễn giải AC để lấp gap — hãy để nó liệt kê rõ điểm mơ hồ, tương tự kỹ thuật đã dùng ở bài 1 cho user story sơ sài, rồi đưa lại cho PO/BA làm rõ trước khi bổ sung test case.
Mẹo: Khi báo cáo gap cho PO/BA, luôn tách rõ "gap do thiếu test case" (lỗi của QA, cần bổ sung) và "gap do AC mơ hồ" (cần PO/BA làm rõ trước) — trộn lẫn hai loại này trong một báo cáo dễ khiến PO/BA hiểu lầm rằng mọi gap đều là lỗi thiếu test.
Làm Thế Nào Để Cải Thiện Prompt Dựa Trên Những Gì Bạn Tìm Thấy Khi Review?
Review không chỉ để sửa test case hiện tại — nó là nguồn dữ liệu quý để cải tiến prompt gốc, giảm dần số lỗi cần sửa tay ở các lượt generate sau.
Vòng Lặp Cải Tiến Prompt (Prompt Improvement Feedback Loop)
Vòng lặp gồm 4 bước lặp lại: (1) generate test case bằng prompt hiện tại; (2) review theo checklist, ghi lại loại lỗi gặp phải; (3) sửa prompt để ngăn loại lỗi đó xuất hiện lại (thêm rule cụ thể, thêm ví dụ counter-example); (4) chạy lại prompt mới cho feature tiếp theo, so sánh tỉ lệ lỗi. Vòng lặp này biến việc review từ "công việc lặp lại tốn thời gian" thành "đầu tư giảm dần thời gian review theo thời gian".
Ánh Xạ Phát Hiện Review Sang Chỗ Sửa Prompt
Bảng dưới đây map lỗi thường gặp (đã nói ở đầu bài) sang cách sửa prompt cụ thể:
| Lỗi phát hiện khi review | Cách sửa prompt |
|---|---|
| Observable-Result Substitution | Thêm rule: "Expected result must describe only externally observable outcomes (UI, message, visible state) — never internal system/DB state" |
| Precondition Ambiguity | Yêu cầu format precondition cụ thể: "State exact data condition, not just 'user has an account'" |
| Happy-Path Inflation | Ép tỉ lệ tối thiểu: "At least 40% of generated cases must be negative or edge" |
| Shallow Negative Paths | Chỉ định rõ 4 nhóm negative path (business rule, system-state, concurrency, external dependency) như ở bài 1 |
| Missing State-Transition Tests | Luôn kèm danh sách valid transitions, yêu cầu liệt invalid transitions tương ứng |
| Untestable Steps | Ghi rõ kênh test (manual UI / automation) ngay đầu prompt |
Log Phiên Bản Hóa và Cải Tiến Prompt
Lưu lại từng phiên bản prompt kèm ghi chú thay đổi — tương tự changelog code — để bạn (và cả team) hiểu vì sao prompt hiện tại trông như vậy, và không vô tình quay lại lỗi cũ khi có người khác chỉnh sửa prompt sau này.
Mẹo: Mỗi lần sửa prompt để chặn một lỗi cụ thể, chỉ thêm đúng 1 rule và chạy lại ngay trên feature vừa review để xác nhận lỗi đó không còn tái diễn — đừng gộp sửa nhiều rule một lúc rồi đợi tới sprint sau mới kiểm tra, vì khi đó bạn sẽ không biết chính xác rule nào thực sự có tác dụng.
Prompt Template: Feature Test Case Generation v1.3
CHANGELOG:
v1.0: Base prompt, only positive/negative coverage
v1.1: Added edge case category after finding domain-specific edge
cases were consistently missing
v1.2: Added explicit "observable outcome only" rule after finding
DB-state expected results in 30% of generated negative paths
v1.3: Added minimum 40% negative/edge ratio rule after happy-path
inflation found in sprint 22 review
[... full current prompt below ...]
A/B Testing Các Biến Thể Prompt
Với thay đổi prompt lớn (không chỉ thêm 1 rule nhỏ), hữu ích khi chạy A/B: dùng cùng một feature/context, chạy cả prompt cũ và prompt mới, so sánh kết quả qua checklist review, rồi quyết định version nào thắng trước khi áp dụng chính thức cho cả team — tránh việc "cảm thấy" prompt mới tốt hơn mà không có dữ liệu so sánh thật.
Xây Chuẩn Chất Lượng Prompt Cho Cả Team
Khi vòng lặp cải tiến đã chạy được vài sprint, hợp nhất các bài học vào một "prompt chuẩn" chung của team (không phải để mỗi người tự giữ prompt riêng), kèm theo bộ tiêu chí review dùng chung. Điều này đảm bảo chất lượng test case do AI tạo không phụ thuộc vào việc ai là người ngồi prompt hôm đó.
Prompt Của Chúng Ta Được Thiết Kế Để Tạo Ra Gì?
Phần này không phải một nhóm kỹ thuật mới, mà là một bản tuyên bố kỳ vọng chất lượng (quality expectations) rõ ràng, nên đính kèm ngay trong prompt chuẩn của team để AI luôn "neo" theo đúng chuẩn, không trôi dần qua từng lần chạy khác nhau.
Chất Lượng Expected Result Kỳ Vọng
Expected result phải: cụ thể, quan sát được từ bên ngoài, không mơ hồ, và verify được bởi một tester chưa từng biết hệ thống trước đó — nếu một tester mới hoàn toàn có thể đọc expected result và biết chính xác cần nhìn vào đâu để pass/fail, đó là chất lượng đạt chuẩn.
Chuẩn Coverage Kỳ Vọng
Mỗi AC phải có tối thiểu một positive, và nếu logic AC có khả năng sai (có điều kiện, có ràng buộc dữ liệu), phải có thêm ít nhất một negative tương ứng — không chấp nhận suite mà 80%+ là positive path như đã cảnh báo ở lỗi phổ biến số 3.
Chuẩn Precondition Kỳ Vọng
Precondition phải nêu rõ trạng thái dữ liệu cụ thể (không dùng cụm mơ hồ như "đã có tài khoản"), nêu rõ vai trò/quyền của actor, và nêu rõ trạng thái hệ thống liên quan (session, cấu hình feature flag nếu có) — đủ để một tester khác, ở thời điểm khác, tái lập đúng chính xác điều kiện ban đầu của test case.
Mẹo: Dán nguyên 3 mục chuẩn chất lượng này (Expected Result/Coverage/Precondition) vào ngay đầu prompt chuẩn của team, không chỉ lưu làm tài liệu tham khảo riêng — rule chỉ thực sự có tác dụng khi nó nằm trong context mà AI đọc mỗi lần generate, không phải nằm trong một trang wiki mà không ai paste vào prompt.