Một trong những công việc tốn thời gian nhất của QA không phải là chạy test, mà là nghĩ ra test case. Đọc một user story, một spec kỹ thuật dài 5 trang, rồi tự hỏi "mình đã cover hết case chưa?" — đó là công việc lặp đi lặp lại mỗi sprint. AI, khi được prompt đúng cách, có thể rút gọn công việc này từ vài giờ xuống vài phút, miễn là bạn hiểu AI đang thực sự làm gì và biết cách kiểm soát output của nó. Bài này đi sâu vào kỹ thuật trích xuất test case từ requirement, cách tạo đồng thời positive path, negative path và edge case, cách review lại kết quả AI sinh ra, và cách đưa nó vào test management tool một cách có hệ thống.
Làm Thế Nào Để Dùng AI Trích Xuất Testable Scenarios từ User Stories và Specs?
Trích xuất scenario không phải là "tóm tắt lại story". Nó là quá trình chuyển một câu chuyện mô tả ý định của người dùng thành một danh sách các hành vi có thể kiểm chứng. Đây là kỹ năng nền, và nếu làm sai ngay từ bước này, mọi bước sau (BVA, exploratory, review...) đều xây trên một nền không chắc.
AI Đang Thực Sự Làm Gì?
Khi bạn đưa một user story vào AI và yêu cầu "generate test case", model không "hiểu" nghiệp vụ như một BA có 5 năm kinh nghiệm. Nó đang làm ba việc: (1) nhận diện các danh từ trong story để suy ra actor, object, state; (2) nhận diện các động từ có điều kiện (nếu, khi, chỉ khi) để suy ra logic rẽ nhánh; (3) áp mẫu (pattern) test case phổ biến nhất mà nó đã thấy trong dữ liệu huấn luyện — thường là mẫu happy-path đơn giản. Hiểu rõ điều này giúp bạn biết vì sao AI hay bỏ sót các case ẩn: nó chỉ suy luận được từ những gì được viết ra, không suy luận được từ những gì tác giả story "ngầm hiểu" nhưng không viết. Vai trò của bạn là cung cấp đủ ngữ cảnh (context) để lấp khoảng trống đó — chứ không phải kỳ vọng AI tự đoán.
Mẹo: Trước khi viết prompt, tự hỏi "câu chuyện này có che giấu điều kiện ngầm nào không (ví dụ: quyền hạn, trạng thái dữ liệu trước đó)?" Nếu có, hãy nêu rõ nó trong prompt — đừng để AI đoán.
Mô Hình Trích Xuất: Feature Behaviors + States + Actors
Cách hiệu quả nhất để trích xuất scenario có hệ thống là chia requirement thành 3 lớp trước khi prompt AI:
- Actors — ai tương tác với feature này (guest, user đã đăng nhập, admin, hệ thống bên thứ ba...).
- States — trạng thái dữ liệu/hệ thống tại từng thời điểm (giỏ hàng trống, tài khoản bị khóa, session hết hạn...).
- Behaviors — hành động mà actor thực hiện trên một state cụ thể, dẫn tới kết quả nào.
Khi bạn tách 3 lớp này ra trước, rồi đưa vào prompt như một bảng, AI sẽ sinh ra scenario có độ phủ (coverage) cao hơn nhiều so với việc chỉ dán nguyên user story và bảo "generate test case".
Prompt Trích Xuất Cơ Bản
Đây là prompt nền (base prompt) bạn có thể dùng làm điểm khởi đầu, rồi tùy biến theo feature:
ROLE: You are a senior QA analyst specializing in requirement decomposition.
TASK: Read the user story below and extract all testable scenarios.
Do NOT write test steps yet — only list scenarios in this format:
- Actor:
- Precondition (state):
- Action:
- Expected outcome category (success / validation error / system error):
USER STORY:
"""
As a registered user, I want to update my profile avatar,
so that other users can recognize me in comments.
"""
ACCEPTANCE CRITERIA:
- Accepted formats: JPG, PNG (max 5MB)
- Avatar must be cropped to 1:1 ratio before upload
- If upload fails, user sees an inline error, not a redirect
INSTRUCTIONS:
1. List at least 3 actors/roles if the story implies more than one.
2. For each actor, list every distinct state before the action.
3. Do not merge two different failure conditions into one scenario.
Chạy prompt này trước, xem output có bao nhiêu scenario, rồi mới yêu cầu AI viết step chi tiết ở bước sau. Tách hai bước — trích xuất scenario và viết step — giúp bạn review nhanh hơn và tránh việc AI "vừa nghĩ vừa viết" khiến bỏ sót case.
Xử Lý Flow Nhiều Màn Hình
Với feature trải qua nhiều bước (checkout, onboarding, wizard nhiều màn hình), đừng đưa cả flow vào một prompt duy nhất — AI có xu hướng "rút gọn" các bước giữa để tiết kiệm token, dẫn đến bỏ sót case ở bước trung gian. Thay vào đó, chia nhỏ theo từng màn hình/bước, prompt riêng cho mỗi bước, sau đó yêu cầu AI tổng hợp lại thành một flow test case xuyên suốt ở bước cuối. Ví dụ với flow thanh toán 4 bước (giỏ hàng → địa chỉ → thanh toán → xác nhận), hãy trích scenario cho từng bước, rồi thêm một prompt riêng: "Given the 4 step-level scenario lists above, generate end-to-end scenarios that cross step boundaries (e.g., user goes back from step 3 to step 1)."
Trích Xuất từ Technical Specs (Không Phải User Stories)
Technical spec (API spec, DB schema, sequence diagram mô tả bằng text) khác user story ở chỗ nó không có "actor" rõ ràng và thường viết theo góc nhìn hệ thống. Khi trích xuất từ spec kỹ thuật, prompt cần yêu cầu AI dịch ngược từ góc nhìn hệ thống sang góc nhìn người dùng/QA:
TASK: The document below is a backend API spec, not a user story.
Translate each endpoint behavior into a QA-testable scenario from
the perspective of the client calling it.
For each endpoint, extract:
- Valid request scenarios
- Invalid request scenarios (missing field, wrong type, wrong auth)
- Scenarios triggered by upstream/downstream system state
(e.g., third-party service timeout, DB constraint violation)
Điểm khác biệt quan trọng: spec kỹ thuật thường mô tả rất chi tiết field-level nhưng thiếu ngữ cảnh nghiệp vụ (business context). Nếu có thể, luôn đính kèm thêm 1-2 câu mô tả nghiệp vụ khi feed spec vào AI, nếu không kết quả sẽ chỉ toàn test case dạng "trường A required" mà thiếu case về hành vi nghiệp vụ.
Xử Lý User Stories Sơ Sài hoặc Viết Kém
Thực tế phần lớn story trong backlog không đủ chi tiết. Đừng cố "vá" story bằng cách tự đoán rồi feed cho AI — hãy làm ngược lại: dùng AI để chỉ ra chỗ thiếu trước khi generate test case.
The user story below may be incomplete. Before generating test cases,
list every ambiguous point that would block you from writing a
deterministic test case (e.g., undefined error message, unclear
permission boundary, missing data format). Do not guess — just list
the gaps as questions for the PO/BA.
Cách làm này biến AI thành công cụ phát hiện thiếu sót của backlog, thay vì một cái máy tạo ra test case "đẹp nhưng sai" dựa trên giả định sai lệch. Sau khi gap được làm rõ (qua trao đổi với PO/BA), bạn mới chạy lại prompt trích xuất scenario ở trên.
Làm Thế Nào Để Prompt AI Tạo Positive Path, Negative Path và Edge Case Cùng Lúc?
Nếu chỉ prompt "generate test case cho feature X", AI gần như luôn ưu tiên positive path và bỏ sót negative path, edge case. Muốn có độ phủ đầy đủ trong một lượt, bạn cần ép cấu trúc output ngay trong prompt, không để AI tự quyết định tỉ lệ.
Cách Tiếp Cận Coverage Matrix
Coverage matrix là một bảng 2 chiều: một chiều là loại input/điều kiện, chiều còn lại là loại kết quả mong đợi (thành công, lỗi validate, lỗi hệ thống). Khi bạn yêu cầu AI điền vào matrix này thay vì viết tự do, nó buộc phải sinh case cho từng ô, kể cả những ô mà bình thường nó sẽ bỏ qua.
Build a coverage matrix with rows = input conditions
(valid, boundary, invalid-format, invalid-business-rule, missing)
and columns = expected outcome type
(success, inline validation error, blocking error, silent no-op).
Fill every cell that is logically possible; write "N/A" only if a
cell is truly impossible given the requirement, and explain why.
Mẹo: Luôn yêu cầu AI giải thích lý do khi nó đánh "N/A" vào một ô — nhiều lần "N/A" thực chất là case AI bỏ sót chứ không phải case không tồn tại.
Đào Sâu Việc Tạo Negative Path
Negative path không chỉ là "nhập sai format". Có ít nhất 4 nhóm negative path mà AI thường bỏ sót nếu không được nhắc: (1) sai theo business rule (dữ liệu đúng format nhưng vi phạm logic nghiệp vụ, ví dụ ngày kết thúc trước ngày bắt đầu); (2) sai do trạng thái hệ thống (session hết hạn giữa lúc submit); (3) sai do tương tác đồng thời (2 user cùng sửa 1 record); (4) sai do phụ thuộc bên ngoài (API bên thứ ba trả lỗi). Prompt riêng cho negative path nên liệt rõ 4 nhóm này:
Generate negative-path test cases across these 4 categories only:
1) Business-rule violations (data is well-formed but breaks a rule)
2) System-state failures (expired session, locked record, timeout)
3) Concurrency conflicts (two actors acting on the same resource)
4) External-dependency failures (third-party API error/timeout)
Give at least 2 scenarios per category. Do not repeat simple
format-validation cases already covered elsewhere.
Tạo Edge Case với Lý Luận Theo Ngữ Cảnh Cụ Thể
Edge case chung chung ("nhập ký tự đặc biệt", "nhập chuỗi rất dài") ít giá trị vì không gắn với ngữ cảnh nghiệp vụ cụ thể. Edge case có giá trị cao là edge case xuất phát từ đặc thù domain. Ví dụ, với feature "đặt lịch hẹn", edge case đáng giá là "đặt lịch đúng thời điểm chuyển múi giờ do DST (Daylight Saving Time)", không phải "nhập tên có emoji". Prompt nên ép AI tự lý luận theo domain trước khi liệt case:
Before listing edge cases, first identify 3-5 domain-specific
"stress points" for this feature (e.g., timezone transitions,
rounding in financial calculations, rate limits, pagination
boundaries). Then generate one edge case test per stress point,
explaining why that stress point is uniquely risky for this feature.
Kết Hợp Cả Ba trong Một Lượt Có Cấu Trúc
Khi đã tách riêng 3 nhóm, bạn có thể yêu cầu AI trình bày kết quả cuối theo cấu trúc rõ ràng để dễ import và review. Ví dụ output mong đợi có dạng:
Combine the positive paths, negative paths, and edge cases above
into one final structured list, grouped under three headers:
POSITIVE PATHS, NEGATIVE PATHS, EDGE CASES. Number each test case
within its group. Keep the same level of step detail across all
three groups — do not write positive paths in more detail than
negative paths.
POSITIVE PATHS
Nhóm này là baseline — các luồng đúng, dữ liệu hợp lệ, điều kiện tiêu chuẩn. Vì đây là nhóm AI tự nhiên làm tốt nhất, việc review chỉ cần tập trung xem đã cover đủ biến thể vai trò (mỗi actor một case) hay chưa, thay vì lo về độ chính xác.
NEGATIVE PATHS
Nhóm này cần review kỹ nhất vì đây là nơi AI hay generic hóa. Kiểm tra từng case xem expected result có mô tả hành vi hệ thống thực tế (thông báo lỗi cụ thể, mã lỗi, trạng thái UI) hay chỉ ghi mơ hồ "hiển thị lỗi".
EDGE CASES
Nhóm này nên được đối chiếu lại với domain thực tế — nếu case nào không thể xảy ra trong hệ thống của bạn (ví dụ hệ thống không hỗ trợ đa múi giờ), hãy loại nó ra thay vì giữ cho "có vẻ đầy đủ".
Làm Thế Nào Để Review AI-Generated Test Cases Để Đảm Bảo Đầy Đủ và Chính Xác?
Không bao giờ import thẳng output AI vào test management tool. Luôn có một bước review có cấu trúc — không phải đọc lướt, mà là review theo checklist.
Ba Cấp Độ Review
- Cấp câu chữ (wording) — bước có đủ chi tiết để một QA khác thực hiện được không, không cần hỏi lại.
- Cấp logic — expected result có đúng với business rule thật không, hay AI "bịa" ra hành vi hợp lý nhưng sai với hệ thống thực tế.
- Cấp coverage — so với acceptance criteria, có case nào bị thiếu hoàn toàn không.
Review theo 3 cấp riêng biệt (không trộn) giúp bạn không bị "chìm" trong chi tiết câu chữ mà quên kiểm coverage tổng thể.
Checklist Cờ Đỏ (Red-Flag) về Testability
Một số dấu hiệu cho biết test case AI sinh ra có vấn đề, cần sửa ngay:
- Expected result dùng động từ mơ hồ: "hoạt động đúng", "hiển thị phù hợp" — không có tiêu chí kiểm chứng cụ thể.
- Step hành động gộp 2-3 hành động vào 1 bước ("đăng nhập và tạo đơn hàng và xác nhận").
- Precondition không nêu rõ trạng thái dữ liệu, chỉ nói "user đã có tài khoản".
- Test case negative path có expected result giống hệt positive path (dấu hiệu AI copy-paste template).
Mẹo: In checklist cờ đỏ này ra và dán ngay cạnh màn hình khi review — review theo checklist cố định nhanh hơn và ít bỏ sót hơn nhiều so với đọc tự do.
Dùng AI để Tự Review Lại Output của Chính Nó
Một kỹ thuật hiệu quả là dùng chính AI, trong một lượt hội thoại mới (để tránh thiên lệch do đã "cam kết" với output trước), để review lại output đó với vai trò khác:
ROLE: You are a strict QA lead reviewing test cases written by a
junior tester (the test cases below were actually AI-generated,
but review them as if a human wrote them — do not go easy).
For each test case, flag:
- Any expected result that is not objectively verifiable
- Any step that combines more than one action
- Any missing precondition that could make the test non-deterministic
TEST CASES:
[paste generated test cases]
Kỹ thuật này không thay thế review của con người, nhưng lọc ra được phần lớn lỗi cấp câu chữ trước khi bạn dành thời gian cho review logic/coverage sâu hơn.
Làm Thế Nào Để Lưu AI-Generated Test Cases Vào Test Management Tool?
Test case tốt nhưng nằm rải rác trong chat AI thì vô dụng. Bước cuối là chuẩn hóa và đưa vào công cụ quản lý test (TestRail, Zephyr, Xray, Qase...) một cách có hệ thống, không copy-paste tay từng case.
Cấu Trúc Output AI để Import
Hầu hết test management tool hỗ trợ import CSV/Excel với cột cố định. Thay vì để AI trả lời bằng văn xuôi, ép nó xuất đúng theo cột bạn cần:
Output the final test cases as a markdown table with these exact
columns, ready to convert to CSV:
| Test ID | Title | Precondition | Steps | Expected Result | Priority | Type |
Rules:
- Steps column: numbered steps separated by newline characters
- Priority: High/Medium/Low based on user-facing impact
- Type: Positive/Negative/Edge
Chuẩn Metadata cho Test do AI Tạo
Vì test case AI sinh ra sẽ được review và cập nhật liên tục, hãy gắn thêm metadata ngay từ đầu để về sau dễ truy vết:
source: link tới user story/spec gốc.generated_by: đánh dấu rõ "AI-generated, human-reviewed" — minh bạch với team và audit sau này.review_status: draft / reviewed / approved.prompt_version: phiên bản prompt đã dùng (hữu ích khi bạn cải tiến prompt về sau, xem lại vì sao case cũ khác case mới).
Quy Trình Import Hàng Loạt (Bulk Import)
Quy trình khuyến nghị theo 4 bước: (1) generate ra markdown table; (2) review theo checklist ở phần trên, sửa trực tiếp trong table; (3) convert sang CSV (dùng script nhỏ hoặc paste vào Google Sheets rồi export); (4) import vào tool qua tính năng bulk-import có sẵn, map cột đúng với field của tool. Luôn import vào một folder/suite nháp trước, kiểm tra lại lần cuối trên UI thật của tool rồi mới di chuyển sang suite chính thức — tránh làm loạn suite hiện có nếu import sai cột.
Mẹo: Giữ lại file CSV gốc đã import (kèm ngày, tên feature) trong một thư mục lưu trữ riêng — nó chính là "biên bản" cho biết bộ test case này sinh ra từ đâu, hữu ích khi có tranh cãi về coverage sau này.
Giữ Liên Kết Test do AI Tạo với Requirement Gốc
Traceability là thứ dễ mất nhất khi generate test case bằng AI theo lô lớn. Ngay trong bước generate, luôn yêu cầu AI gắn ID requirement/AC vào mỗi test case:
For every test case, add a column "Linked AC" referencing the
specific acceptance criteria ID it verifies (e.g., AC-02). If a
test case verifies more than one AC, list all IDs comma-separated.
If a test case does not map to any AC, flag it explicitly as
"exploratory / no direct AC" instead of leaving the column blank.
Việc này giúp bạn dựng traceability matrix (sẽ nói kỹ hơn ở các bài sau của module) ngay từ lúc tạo, thay vì phải làm lại thủ công sau.