An assistant drafts thirty test cases in ninety seconds. The professional skill is the ten-minute review gate that follows: score coverage against a rubric, trace every case to a requirement line, and delete the hallucinated behavior before anything enters TestRail.
Tier: Foundation · Workflow area: Test design & planning
This playbook is the foundation move of AI-assisted QA: turn acceptance criteria into a candidate test suite fast, then apply a disciplined human gate so speed never becomes noise. The generation is a commodity. The gate — catching gaps, duplicates, and invented features — is what you are paid for.
When NOT to use:
Assemble the source packet. Paste the user story, every acceptance criterion (numbered — you will trace against these numbers), known constraints, and any API or UI contract. Strip customer names and personal data before anything leaves your machine.
Prompt for structured candidates, not prose. Force a table so the output imports cleanly and reviews quickly:
You are drafting CANDIDATE test cases for human review. Do not invent behavior:
every case must cite the AC number it verifies. If a behavior seems implied but
is not written, list it under "OPEN QUESTIONS" instead of writing a case for it.
Story: [paste]
Acceptance criteria (numbered): [paste]
Constraints: web app, logged-in users only, EUR and INR currencies.
Output a markdown table: ID | Title | Preconditions | Steps | Expected result |
Priority (P1-P3) | Source AC.
Cover: happy paths, negative cases, boundary values, permission variants.
Then list OPEN QUESTIONS separately.
Demand the model attack its own output. Same conversation, before you review:
Review the table you produced. Which ACs have no covering case? Which cases
duplicate each other? Which cases assert behavior not present in any AC?
Answer as three lists: GAPS, DUPLICATES, UNSUPPORTED.
A good result looks like this — the model catching its own invention is the point:
UNSUPPORTED:
- TC-14 asserts a confirmation email is sent. No AC mentions email.
- TC-22 assumes admin users bypass the limit. AC-6 says the limit is universal.
Run the human gate with a coverage rubric. Score the suite yourself against a fixed checklist: every AC has ≥1 positive and ≥1 negative case; boundaries tested at, below, and above each limit; role/permission variants present; error paths asserted with specific messages, not "an error is shown." Anything the self-critique flagged gets your verdict, not the model's.
Trace and prune. Delete every case whose Source AC column you cannot verify by re-reading the requirement. Merge duplicates. Rewrite vague expected results ("works correctly") into observable outcomes. Take the OPEN QUESTIONS list to the product owner — these are usually real requirement bugs.
Import the survivors. Convert to your test-management format and load:
Convert the approved cases to TestRail CSV import format with columns:
"Title","Precondition","Steps","Expected Result","Priority","References".
Steps separated by newlines within the cell. Output raw CSV only.
csvlint approved-cases.csv && head -3 approved-cases.csv
Then TestRail: Cases → Import from CSV; Xray: Test Case Importer. Keep the References column pointing at AC numbers — that is your traceability for free.
Never bulk-import directly from model output to your test-management tool. The import step must consume only the reviewed file, or the gate silently disappears from your process within a sprint.
Generation compresses hours of typing into minutes; it does not compress judgment. The suite that enters your tool must be one a reviewer signed, traced, and pruned — the AI wrote candidates, you wrote the coverage.