AI can draft forty test cases in ninety seconds. The professional skill is the review gate that catches the hallucinated behavior hiding in case 23. This module rebuilds test design around generation-plus-gate: testability critique, BDD with vague-step detection, edge-case ideation and risk-based regression scoping — with coverage judgment staying yours.
The evidence frame is unambiguous. Stack Overflow's 2025 survey puts testing at the very top of planned AI uses among developers, and PractiTest's State of Testing 2026 has 78.8% of testing professionals calling AI the most impactful trend of the next five years — while 65.6% of the same respondents say they are very concerned about the future of the profession. Both numbers describe the same fork: testers who can only execute test cases compete with generation; testers who can judge generated test cases become more valuable than they were before. This module is the judging skill.
Ramesh — twelve years in QA, test lead on a corporate-lending portal for a banking client in Chennai — gets six user stories on repayment scheduling. Old estimate: two days of test design.
He pastes the acceptance criteria into the client-approved LLM. Forty-two test cases in ninety seconds — positive, negative, boundary, all neatly formatted for TestRail import. It feels like a superpower. He imports all of them.
A production defect: a borrower who repays on the exact due date is charged a late fee. Ramesh checks the suite — case 23 covered this. It reads: "Verify repayment on due date is accepted within the 30-day grace period."
There is no 30-day grace period. Not in the stories, not in the product. The model invented a plausible banking behavior, wrote a test against the invented rule, and the test "passed" because the tester executing it assumed the spec knew something they didn't. Two other cases silently duplicated each other, and one boundary — due date falling on a bank holiday — was never generated at all.
Ramesh rebuilds his workflow: generation stays, but nothing enters the suite until it survives a scored review gate — every expected result traced to a source line in the requirements, duplicates clustered, boundaries checked against a technique list. The gate takes forty minutes. The two days are still saved.
The lesson generalizes: the model is a tireless, fast, occasionally confident-and-wrong test-design partner. Speed is no longer the differentiator — everyone has speed now. The differentiator is the review discipline that makes speed safe, and that discipline is trainable.
For twenty years, writing test cases was the work. Now a model produces a plausible first draft of that work in seconds, and every AI-enabled test-management tool — TestRail, Xray, qTest — ships a generate button. What none of them ship is the gate. Watch what actually changed in Ramesh's workflow:
The LLM produces 42 cases. They look professional — consistent format, reasonable titles, plausible expected results. They import cleanly. The suite grows, coverage appears to grow, and three specific defect types ride in unexamined: hallucinated behavior stated as fact, near-duplicate cases inflating the count, and missing boundaries that generation simply never reached.
The same 42 cases hit a scored review. Every expected result must cite the requirement line that supports it — case 23's "30-day grace period" fails instantly because no line exists. Duplicates are clustered and merged. The case list is checked against a boundary-technique checklist, which surfaces the bank-holiday gap the model missed. What enters the suite is 31 cases, each defensible in an audit.
The gate has three checks, and each targets a distinct, documented failure mode of generated test cases:
Assessment scenarios in this domain show you AI-generated test cases containing planted defects — a wrong expected result, a duplicated pair, a missed boundary. The scored skill is finding all of them and naming which gate check caught each one, not generating more cases.
The cheapest defect to fix is the one in the requirement, and adversarial critique is something LLMs are genuinely strong at when you aim them correctly. Instead of "generate test cases for this story," the sharper opening move is: "You are a skeptical test lead. List everything in this story that is ambiguous, untestable, contradictory, or missing an acceptance criterion. Phrase each finding as a question I can ask the product owner."
Run that against a real backlog and the results are immediately billable: undefined error behaviors, two ACs that cannot both be true, "should be fast" with no number attached, roles mentioned in the description but absent from the criteria. Ramesh now runs this pass in refinement, before sprint start — the same skill static testing always taught, at a speed that makes it viable for every story instead of the risky few. Two disciplines keep it honest:
The same pattern extends to BDD. Gherkin generation from acceptance criteria is table stakes — every vendor demo shows it. The taught skill is the second pass: a critique prompt that flags vague steps ("When the user enters invalid data" — which field? invalid how?), steps that hide three assertions in one line, and Then-clauses that no automation could verify. Vague steps calcify: once step definitions exist, the ambiguity is load-bearing.
AI does not replace boundary-value analysis, equivalence partitioning or pairwise reduction — it makes them cheap enough to apply everywhere. The workflow that works is technique-directed generation: name the technique in the prompt and demand the analysis, not just the list.
| Technique | Prompt direction | What the human still owns |
|---|---|---|
| Boundary values | "Identify every numeric, date and length boundary in this spec; give below/on/above cases for each" | Spotting the boundary the spec implies but never states |
| Equivalence classes | "Partition the input space; one representative per class; justify each partition" | Rejecting partitions that don't match real system behavior |
| Pairwise | "List the parameters and values, then a pairwise-reduced combination set" | Deciding which pairs are risk-critical enough to test exhaustively (verify with PICT/AllPairs — models miscount combinations) |
| Locale & time traps | "Generate cases for timezone, DST, leap-day, Unicode and RTL hazards in this feature" | Knowing which locales the product actually serves |
| Negative & abuse | "What inputs would a hostile or careless user try here?" | Routing security-class findings to the security team |
Two cautions carry across all five rows. Generated combinatorial sets need mechanical verification — a pairwise matrix from an LLM can look systematic while missing pairs, so the free tools (PICT, AllPairs) remain the source of truth and the model remains the ideation layer. And volume is not coverage: two hundred generated negatives that all exercise the same validation path are one test case wearing two hundred costumes. Cluster before you count.
Keep a per-product "trap list" — the boundaries and locale hazards that have actually bitten your product — and paste it into every ideation prompt. Grounding generation in your product's real failure history is the single cheapest quality upgrade, and it compounds every sprint.
Three planning artifacts round out the module, each with the same shape — AI drafts, human owns the risk call:
A traceability matrix is an audit artifact. Never ship a generated matrix without verifying the links — a model asked to map 200 cases to 40 requirements will produce a complete-looking grid, and completeness is precisely what it hallucinates under pressure.
Test design with AI is a two-stage discipline: generate wide, then gate hard. Trace every expected result to a source line, cluster duplicates, check boundaries against technique — because the model's forty-two cases are a draft, and the thirty-one that survive your gate are the product. The gate, not the generation, is the skill you are paid for.
Take this into Lab 01 (test-case generation with a review gate) — the requirements doc has planted ambiguities and one contradictory acceptance criterion, and the answer key lists every defect your gate should catch. Companion playbooks: pb-01 through pb-07.