You have forty user stories in the sprint backlog and one QA engineer with three days. Somebody has already suggested pasting the acceptance criteria into ChatGPT, and somebody else tried it and got back thirty test cases that read well and cannot be executed.
Both people are right. AI test case generation produces a usable first draft in minutes, and it collapses on a one-line prompt, because a model handed no output contract optimizes for sounding helpful over being runnable. The fix lives in the structure of the prompt rather than the choice of model: four fixed parts in the input, then a critique pass that scores the draft against six risk lenses and regenerates only the gaps.
What comes back is Gherkin, one scenario per case, tagged P0 to P2, each row traced to the criterion it covers, ready for the Xray, TestRail, or Jira importer. Below is the template, the loop, the review rubric, and the honest cutover point.
Why AI Test Case Generation Returns Garbage on a One-Liner Prompt
The prompt most teams start with is some version of “generate test cases for this requirement,” and it returns a list a manager accepts and a tester cannot use. Stack Overflow found the most common frustration with AI tools was “AI solutions that are almost right, but not quite,” reported by 66% of respondents.
The Four Things a One-Liner Prompt Is Missing
- Input structure. Given only prose, the model invents the feature’s boundaries and guesses what a “tenant” means in your product.
- Output format. Freeform prose returns “Verify that the user can log in,” where Gherkin returns a Given, When, and Then a tester can run.
- Tagging. Untagged cases arrive as a flat list, while a risk column turns it into a P0 subset you run on every build.
- Edge-case scope. Left open, the model produces happy paths and one null check instead of session expiry and tenant isolation.
Why the Output Looks “Reasonable” but Isn’t Runnable
Cases duplicate across stories, because the model carries no memory of the story it processed a minute earlier, and nothing traces back to a criterion, so coverage cannot be reported. Steps arrive as narrative sentences two testers read two ways, and every case carries the same implied priority, so the suite cannot be cut down when the date moves.
The Bar This Article Holds Itself To
This guide holds itself to three artifacts: one prompt template, one critique loop, one review rubric. Paste all three into Claude, ChatGPT, or Gemini and you should generate test cases from requirements that come back deduplicated, risk-tagged, and traced.
The Four-Part Prompt Template
Every part below removes one specific failure named above. The order matters, because the model reads the input contract first and the guardrails last, and the guardrails are where a cap on case count takes effect.
Input Structure
Four inputs, in this order: the requirement text, the acceptance criteria as a bulleted list rather than a paragraph, the tech-stack context, and the six edge-case classes below. Stack context is the part teams skip and the part that changes the output most.
A model told “Next.js app router, JWT with 15-minute access tokens, Postgres row-level security, nine locales including Arabic” will generate test cases from user stories naming the token refresh window and the right-to-left layout. Strip it out and you get cases that fit any product and test none.
The Ask
Ask for a table where every row is one scenario in Given/When/Then form, plus two columns the model never adds unprompted: a risk column holding P0, P1, or P2, and a traceability column naming the criterion covered. That second column makes coverage reportable and deduplication possible, since the model sees which criteria already carry three cases.
Gherkin, specified by the Cucumber project, earns its place for a second reason. It is the format Xray’s importer reads natively.
Role and Voice Constraint
The role line does real work on verbosity and on triage judgment. Ours reads: “Act as a QA engineer with 8 years of enterprise SaaS experience. Write test cases a human engineer will run today, and skip smoke coverage the CI pipeline already handles.”
Output Guardrails
Deduplicate against the criteria before returning anything, and drop any happy-path case whose Then clause only restates a criterion word for word, since that tests the sentence rather than the software. The third guardrail caps output at three cases per criterion unless a risk lens fires.
# PART 1 - INPUT
REQUIREMENT:
ACCEPTANCE CRITERIA:
- AC1:
- AC2:
- AC3:
TECH-STACK CONTEXT:
- Framework:
- Auth model:
- Data store:
- i18n scope:
EDGE-CASE CLASSES TO COVER:
auth | permissions | concurrency | network | i18n | data-integrity
# PART 2 - THE ASK
Return a table. One row per test case. Columns:
| ID | Title | Given | When | Then | Risk | Traces to |
- Given/When/Then: one line each, no supporting narrative.
- Risk: P0 (release blocker), P1 (this sprint), P2 (backlog).
- Traces to: the exact AC id this case covers.
# PART 3 - ROLE
Act as a QA engineer with 8 years of enterprise SaaS experience.
Write test cases a human engineer will run today.
Skip smoke coverage the CI pipeline already handles.
# PART 4 - GUARDRAILS
- Deduplicate against the acceptance criteria before returning.
- Drop any happy-path case whose Then only restates an AC verbatim.
- Cap at 3 cases per AC, unless an edge-case class above fires,
then lift the cap for that AC only.
- Output the table and nothing else. No preamble, no summary. The Six-Lens Coverage Loop
Most guides on how to write test cases using AI stop at the first prompt, which is where the interesting work starts. A first draft covers what the criteria said out loud, and the loop below finds what they quietly assumed.
The Six Lenses
- Auth. Session expiry mid-action, token refresh on an in-flight request, role escalation after a permission change.
- Permissions. RBAC boundary cases, tenant isolation, a user who loses access while holding an open page.
- Concurrency. Double-submit, two tabs editing one record, optimistic locking conflicts, races on a shared counter.
- Network. Timeouts, retry storms, offline mode, a partial response returning 200 with half the payload.
- i18n. Right-to-left layout, locale date and number formats, strings that break a fixed-width control.
- Data integrity. Nullable fields, boundary values, emoji in names, injection-adjacent free-text input.
The Critique Prompt
Paste the first-draft table back into the same conversation and ask the model to audit its own output against each lens by name. Numbered instructions beat a paragraph here, because the model answers each item in turn while a prose request earns one summarizing sentence.
Here is the suite you just generated:
For each of the six edge-case classes (auth, permissions, concurrency,
network, i18n, data-integrity):
1. List which of my cases cover that class. Cite case IDs.
2. Score coverage of that class: none | partial | adequate.
3. Name what a senior tester would expect to see that I am missing.
Then return ONLY the missing cases, in the same table format.
Do not restate cases I already have. The last line is what saves the time. Without “return only the missing cases,” the model renumbers everything and you lose the review you already did.
When to Stop the Loop
Stop after two passes, or earlier when the model reports adequate coverage on four of the six lenses. A third pass reliably produces cases that are technically valid and commercially pointless.
What the Loop Catches on a Real User Story
Take a plain story: as a returning user, I can sign in with email and password and land on my dashboard. The first draft returned valid credentials, invalid password, locked account, and an empty-field check, then the critique pass scored auth partial, i18n none, concurrency none.
Scenario: Session expires while the dashboard is open [P0, AC3] Given I am signed in and idle past the 15-minute access token TTL When I trigger a dashboard action that calls the API Then the refresh token renews the session silently and the action completes Scenario: Concurrent sign-in from a second device [P1, AC1] Given I am signed in on device A When I sign in with the same credentials on device B Then both sessions stay valid and neither dashboard shows stale data Scenario: Sign-in form in a right-to-left locale [P1, AC2] Given my locale is ar-SA When I open the sign-in form Then labels, the password reveal control, and validation text mirror correctly
None of the three are exotic. All three reach production precisely because the acceptance criteria never mentioned them.
Prompt Snippets Across Claude, GPT-4o, and Gemini
The template runs unchanged on all three major chat models, and each needs one corrective line. Those lines cost nothing and change the output more than switching models.
Claude Sonnet, Tweaks and Per-Suite Cost
Claude runs the critique loop with the least prompting and honors “return only the missing cases” most reliably. Its habit is narrative padding, so append “one line per Given/When/Then, no supporting narrative” to part two. Anthropic lists Claude Sonnet 5 at $2 per million input tokens and $10 per million output.
GPT-4o, Tweaks and Per-Suite Cost
GPT-4o produces the fastest first draft and the weakest lens critique when the lenses arrive as a paragraph. Paste them as a bulleted enumeration instead, the single most useful correction in ChatGPT test case generation. OpenAI lists GPT-4o at $2.50 per million input tokens and $10 per million output.
Gemini 2.5 Pro, Tweaks and Per-Suite Cost
Gemini uses the tech-stack context best, producing ORM-specific data-integrity cases the others miss. Its weakness is Gherkin discipline, so append “strict Given/When/Then, no free-text preamble” to part two. Google lists Gemini 2.5 Pro at $1.25 per million input tokens up to 200,000 tokens and $10 per million output.
Claude Sonnet 5
$2.00
$10.00
One line per Given/When/Then, no supporting narrative
GPT-4o
$2.50
$10.00
Paste the six lenses as a bulleted enum, not a paragraph
Gemini 2.5 Pro
$1.25 (prompts up to 200k)
$10.00
Strict Given/When/Then, no free-text preamble
All three charge the same $10 per million output tokens, and a two-pass run is dominated by output, so output quality should decide the choice rather than price. Read the real token counts from each API’s usage response, and note that Anthropic flags a tokenizer producing roughly 30% more tokens for identical text on newer models.
The Human Review Step
The question underneath this section, phrased the way it gets typed into a search box, is can AI replace manual testers, and the honest answer is no. The model drafts faster than any human, and a tester decides what ships and adds the domain edges the model cannot know about.
The survey data supports that caution. Stack Overflow reports that 46% of developers actively distrust the accuracy of AI output against 33% who trust it.
The Three-Dimension Scoring Rubric (Executability, Uniqueness, Value)
Score every generated case 1 to 3 on three dimensions, then delete anything below 6 of 9. A 6 keeps cases strong on two dimensions and weak on one, and clears the middle that makes AI-drafted suites feel padded.
- Executability. Can a tester run this today with the data that already exists? A fixture nobody built scores 1.
- Uniqueness. Does it cover something no other case covers? Near-duplicates get caught here.
- Value. Does a failure here matter? A broken tenant boundary scores 3, a misaligned tooltip in a tiny locale scores 1.
The Domain Edges Only a Human Catches
Three categories reappear in every review, and none are inferable from a ticket. Business rules that live in support tickets, regressions from recent sprints the model has no memory of, and edge cases specific to an enterprise integration, such as a partner API returning 200 with an error body.
This is where an outsourced pass looks like a QA function rather than a transcription service. It applies the same scoring discipline as our manual testing process.
What the Review Actually Takes
Budget the review explicitly, because it is the step that gets cut first. On a 40-story batch the loop returns a couple of hundred raw cases, and scoring moves at roughly a case every fifteen seconds, so plan on about half surviving and near ninety shipped inside an hour. Treat that as a scoping estimate rather than a measured benchmark, and for a sense of what the maintained suite becomes, our Granola case study documents 1,100+ test cases and 76% of the regression suite automated on an AI notepad product.
Landing the Cases in Jira, TestRail, or Xray Without a Rewrite Pass
The output format was chosen for this section specifically. A Gherkin table sits one transform from every major tracker’s built-in importer, and all three paths below use first-party tooling most teams already license.
Xray on Jira (Cucumber Importer)
Save the scenarios as .feature files and post them to Xray’s import endpoint at /api/v2/import/feature, which also accepts a zip. Scenario tags become labels on the created Test issue, so the risk column arrives as @P0, and a tag before the Feature line links the Test to an existing Jira requirement. Xray notes the Feature description is skipped on import.
TestRail (CSV Importer + Column Mapping)
Export the same table to CSV and open the Import CSV dialog from the test case repository toolbar. TestRail maps columns to case fields on step two and supports value mapping for dropdowns, turning the P0/P1/P2 strings into real priority values. Keep one case per row so the single-row layout applies.
The mapping that works: Title to Title, Given to Preconditions, When to Steps, Then to Expected Result, Risk to Priority, traceability to References. Map every required field or the wizard will not finish.
Jira Native (ScriptRunner / Forge)
Without Xray, create each case as its own issue linked to the story. A ScriptRunner script loops the CSV and creates the issues, and a Forge app does the same through the Jira Cloud issue link API, which Atlassian documents as needing the write:issue-link:jira scope.
What to Skip
Skip the AI-to-tracker integration platforms marketed for this handoff. The prompt output is already CSV-adjacent by design and every importer above is first-party and documented, so that layer solves a problem the output format removed.
When a Plain LLM Stops Being Enough
Four signals mark the point where the loop stops scaling, and they tend to arrive together. Watch for these rather than for a word count on your requirements document.
- The corpus outgrows the context. Past roughly 500 stories, cross-sprint traceability becomes the bottleneck and a chat window cannot see what is already covered.
- Prompt maintenance becomes a job. Four or more hours a week spent tuning prompts belongs in the comparison against a platform license.
- Compliance needs an audit trail. SOC 2, HIPAA, and ISO 27001 scopes want the model and prompt version stamped on each case.
- Recent regressions keep going missing. Test case generation using LLM prompts carries no memory of last sprint’s incidents, so the same gaps reappear.
From there the choice narrows to two routes: run the passes yourself on a purpose-built platform, where our review of the best AI testing tools covers the agentic inventory, or hand the pass to a QA team that already runs it, which is what our AI testing services cover, including prompt engineering support and review of LLM output. That second route prices as Time and Material against a fixed scope, so a first batch is a bounded spend.
When the Loop Ends and the Sprint Begins
The four-part prompt and the six-lens loop get the first draft to runnable, and the scoring pass and tracker import get it into the sprint. Those last two steps decide whether the suite gets used or quietly abandoned.
Run it on one story this afternoon and count how many cases survive scoring. That number tells you more about your requirements than about the model, because the criteria that produce padding were usually vague to begin with.
A QA team can also run the loop and land the cases in your tracker every sprint. If that is the better use of your engineers’ week, contact us and we will scope the first batch against your backlog.
Frequently Asked Questions
How do I get ChatGPT to write good test cases?
Give it the four things a default prompt leaves out: the requirement plus criteria as a bulleted list, an explicit output format (a Gherkin table with risk and traceability columns), a role line telling it to skip coverage your CI already handles, and guardrails that cap cases per criterion.
Then run one critique pass, asking it to score its own output against six risk classes and return only what is missing. That pass separates a list you can run from one that reads well.
What is the best prompt for generating test cases with AI?
A four-part structure beats any single clever sentence: the input block (requirement, criteria, tech-stack context, edge-case classes), the ask (a Gherkin table, one row per case, risk tag, traceability column), a role constraint that skips CI-covered smoke checks, and guardrails that deduplicate and cap per criterion. Follow it with a critique pass across six risk classes, and note the whole thing is one copyable prompt needing no signup.
How do I turn a user story into test cases?
Paste the story text, its criteria as a bulleted list, and your stack context (framework, auth model, data store, locale scope) into the four-part prompt. Run the critique pass so the model audits its draft against auth, permissions, concurrency, network, i18n, and data integrity, then score every surviving case on executability, uniqueness, and value, deleting anything below 6 of 9.
Can AI write test cases better than humans?
No. A model drafts a suite faster than any solo human, and a tester is what makes it worth running, by deleting padding, catching near-duplicates, and adding domain edges the model never saw.
On a 40-story batch, expect a couple of hundred raw cases to reduce to roughly ninety shipped inside about an hour of scoring. The pairing beats either side alone, which is why review belongs in the estimate.
Does this work in Jira, TestRail, or Xray without a rewrite?
Yes, through first-party importers in all three. Xray takes the Gherkin as .feature files through its Cucumber import endpoint, where scenario tags become labels and a feature-level tag links the test to its requirement.
TestRail takes the same table as CSV through its built-in wizard with column and value mapping. Native Jira creates each case as a linked Test issue via ScriptRunner or an Atlassian Forge app on the Jira Cloud REST API.
See how we built and maintained 1,100+ test cases for Granola, an AI notepad, and automated 76% of its regression suite
