Generate from the user story. Then push.
AI is exceptional at turning a feature description into a full set of positive, negative, and edge-case test cases, but only the ones you push it toward. Left alone, its first draft covers the obvious path and stops.
I'm about to test a feature and I want to make sure I'm not just covering the obvious path. Feature: [describe what it does and who uses it] What it's supposed to do: [the acceptance criteria or expected behavior] First, write the test cases you'd consider "standard coverage" for this: the ones most testers would write without thinking too hard. Then, review your own list and tell me: what's missing that a more experienced tester would catch? Specifically look for cases where the input is technically valid but unusual, cases where two valid inputs interact in an unexpected way, and cases where the feature is used in an order nobody planned for. Give me the final list as: ID, short title, setup, steps, expected result. Flag which ones came from the self-audit pass, not the first draft. I want to see the difference.
I need input values that would actually break this field, not ones that just fill it in. Field: [name and purpose of the field] Rules I know about it: [length limits, format, required/optional, anything you've been told] Imagine a tester who's bored, mildly annoyed, and trying to break this on purpose. What would they type? Give me their actual list: the exact values, not categories. Include at least one value that's technically allowed by the rules but that no reasonable person would expect to work correctly, and one value that looks fine to a human but might not be fine to the system underneath it. For each value, one line on what specifically it's testing and why a "normal" input wouldn't have caught it.
Run these back to back on a real ticket. The second prompt is where the coverage that actually catches bugs shows up.
Stop typing "Test User 1."
Realistic data finds the bugs sanitized data never will.
Hand-typed placeholder data hides exactly the bugs that real users trigger on day one in production: an apostrophe in a name, an accented character, an awkward rounding error.
Name: Test User 1
Email: test1@test.com
Amount: $100.00
Name: O'Brien-Núñez, María José
Email: m.o'brien+qa@domain.co.uk
Amount: $9,999.99 (boundary), $0.01 (min)
The data that matters most is the data a tired human stops generating after the third try: boundary values, the one-character-over-the-limit input, the deliberately nasty edge case. That's exactly the generation AI doesn't get tired of doing.
From story to suite.
Take a real feature from your own product (or "user resets their password by email"). Run the Full Coverage Pass prompt, then the Break It On Purpose prompt on whatever field is central to the flow. Finish by generating 5 rows of adversarial test data from what you find.
The three takeaways:
- First drafts are incomplete, not wrong: AI's first pass covers what any tester would think of in two minutes, the standard path and the standard failure. That's what "standard coverage" means
- The self-audit pass is the real skill: ask AI what a more experienced tester would catch that its list missed. It isn't attached to its first draft, so it answers honestly
- "Test User 1" hides bugs: tidy data is too well-behaved to trigger real failure modes: the apostrophe in a name, the boundary value, the one-character-over-the-limit input
Why the second pass matters: that's usually where the real coverage lives, which is exactly why this module built it in instead of trusting the first draft.
On test data: a tester who's bored and mildly annoyed generates better test data than one who's trying to be tidy.
Check yourself: take a test case list you've written or generated recently. Run the self-audit question against it by hand: what's missing that a more experienced tester would catch? If you can name something specific, that's the coverage your first draft was missing.
Want AI to write the actual test code from this?
Everything above is about designing better test cases by hand. QA Smith AI takes your acceptance criteria and generates a production-ready Cypress or Playwright framework directly, grounded in your real app, ready to commit.
Try QA Smith AI →A two-step prompt sequence for full test case coverage
Realistic and adversarial test data generation
Why boundary data finds bugs sanitized data hides
Test Strategy & The Persona Technique.
- Using AI as a reviewer you genuinely can't be for your own work
- The BCU Framework, anchoring strategy to what the business can't afford to break
- A real prompt for defining Business Critical Use Cases