Turning a PRD into test cases with an LLM

You have an eleven-page PRD for a new refund flow, and the sprint starts tomorrow. Writing test cases by hand will take you most of a day. You paste the document into a chat window, ask for test cases, and get back forty numbered rows in ninety seconds.

Half of them are useful. A few are duplicates. And the ones that would have caught the real bug are not there at all.

This guide shows you how to get the useful half faster, and how to find the missing half yourself.

Short version

A PRD is a product requirements document: the written description of what a feature should do.
Feed the model the whole PRD, not a summary. Summaries throw away the details that make good test cases.
Ask for one type of test at a time. One prompt for happy paths, one for negatives, one for boundaries.
Always run a human review pass. Budget about 30 minutes per 40 generated cases.
LLMs reliably miss implicit requirements, cross-feature effects, and anything not written down.
Treat the output as a first draft written by a fast, literal junior tester.

What an LLM is actually good at here

An LLM is a large language model: software that predicts text based on patterns in what it has read. It has no idea what your product does. It only sees the words you give it.

That makes it excellent at a specific job: converting prose into structured rows. A PRD sentence like "users can request a refund within 30 days of purchase" becomes a test case with a precondition, a step, and an expected result. That translation is mechanical, and models are fast and consistent at it.

It also means the model cannot test what the PRD does not say. If nobody wrote down what happens on day 31, the model will either skip it or invent an answer. Both are problems, and the second one is worse.

Step 1: Prepare the input

Do this before you write a single prompt. It takes five minutes and doubles the quality of the output.

Paste the full PRD. Do not summarise it. The details you cut are usually the ones that produce interesting test cases.
Add the data model if you have it. Field names, types, and required flags. refund_amount: decimal, required tells the model far more than "the refund amount".
Add the error strings the app actually returns, such as REFUND_WINDOW_EXPIRED or Insufficient balance. Now expected results can be exact instead of vague.
Add one example of a test case in your team's format. This matters more than any instruction about format.
Say what is out of scope. "Do not generate performance or load tests" saves you deleting fifteen rows later.

Step 2: The prompts

Run these in order, in the same conversation, so the model keeps the context. Replace the bracketed parts.

Prompt A — happy paths

You are a senior QA engineer. Below is a PRD for [feature name].

Generate test cases for the main success paths only. No negative cases, no edge cases yet.

Output a markdown table with these columns: ID, Title, Preconditions, Steps, Expected Result, Priority. Steps must be numbered and specific. Use the example account [email protected] and the URL https://staging.example.com. Expected results must state exact UI text or error codes from the PRD. If the PRD does not specify the text, write UNSPECIFIED IN PRD.

PRD: [paste full PRD]

The UNSPECIFIED IN PRD instruction is the important part. It turns the model's guessing into a visible list of gaps you can take to the product owner.

Prompt B — negative and error cases

Now generate negative test cases for the same feature. Cover: invalid input, missing required fields, wrong permissions, expired or out-of-range values, duplicate submissions, and network or server failure during the action.

For each case, state which PRD line or rule it tests. If a case tests behaviour the PRD does not define, mark it GAP in the ID column. Same table format.

Prompt C — boundaries

List every number, date, length limit, and quantity mentioned in the PRD. For each one, generate three test cases: just below the limit, exactly at the limit, and just above it.

If a limit is implied but not stated (for example a text field with no maximum length), list it separately under "Unstated limits".

Prompt D — the gap hunt

You are now reviewing your own output as a sceptical test lead.

List 10 things that could go wrong with this feature that are NOT covered by the test cases above, and NOT described in the PRD. Focus on: what happens to data created before this feature existed, what other features touch the same data, and what happens when two users act at the same time.

Prompt D produces the highest-value output of the four. It is the only one that pushes past the document.

Step 3: The human review pass

Never ship generated cases straight into your test management tool. Read every row once, and apply these five checks.

Check	What you are looking for	Action
Real?	Does this case describe behaviour the product actually has?	Delete inventions
Testable?	Can you tell pass from fail without asking anyone?	Rewrite vague expected results
Duplicate?	Two rows testing the same rule with different words	Merge
Right level?	A single case doing eight unrelated things	Split
Priority sane?	Everything marked High	Re-rank by risk

A concrete example of the "testable" fix:

Bad (generated): Expected result: The refund is processed correctly.

Good (rewritten): Expected result: Refund row appears in /account/refunds with status "Pending", amount $49.00, and the account balance is unchanged until status becomes "Completed".

Budget roughly 30 minutes of review for every 40 generated cases. If you are spending longer, your PRD input was too thin — fix the input, not the output.

What LLMs always miss

After enough of these runs, the same three holes show up every time.

Implicit requirements

These are the rules everyone in the team knows but nobody wrote down. A refund should not be possible on an order that was already refunded. A cancelled account should not receive marketing email. Money should never display as $NaN.

The model does not know your product's unwritten rules. It has never sat in your standup. Write these down as a permanent "house rules" list and paste it into every prompt.

Negative cases beyond the obvious ones

Models reliably produce "invalid email" and "empty required field". They rarely produce the cases that actually break software: the same request sent twice because the user double-clicked, a session that expires halfway through a multi-step form, a browser back button pressed after submission, or a TypeError: Cannot read properties of undefined (reading 'amount') when an optional API field is absent.

Ask for these by name. They will not appear on their own.

Cross-feature effects

A PRD describes one feature. Bugs live between features. Does the new refund flow change the invoice PDF? Does it fire the same webhook as a cancellation? Does the analytics event now double-count?

Nothing in the document answers those questions, so nothing in the output will either. This is where your product knowledge does work the model cannot.

A realistic before and after

Take one PRD line: "Customers can request a refund within 30 days of purchase."

The model gives you this:

Request refund on day 1 — succeeds
Request refund on day 30 — succeeds
Request refund on day 31 — fails

Fine, and correct. Now the cases you add after the review pass:

Purchase made at 23:59 on 1 May, refund requested at 00:01 on 31 May, customer timezone UTC+9 — which day counts?
Order refunded once already — second request must fail with REFUND_ALREADY_ISSUED
Refund requested while the payment is still Pending at the processor
Refund requested for a partially shipped order
Two support agents click Refund on the same order within one second

Those five are the ones that find bugs. The model gave you the scaffolding; you supplied the danger.

Fitting this into your workflow

Do the generation early, right after the PRD is stable and before development finishes. The gap list from Prompt A and Prompt D is worth more before the code exists than after.

Send the UNSPECIFIED IN PRD and GAP rows to the product owner as a single question list. In practice this is the biggest win of the whole exercise: you find missing requirements days before anyone builds them wrong.

When the generated cases later turn into real bugs, your reports still need real evidence — screenshots, console output, network calls. Tools like Crosscheck capture that automatically from the page, so the loop from generated case to filed bug stays short.

Frequently asked questions

Which model should I use for this? Any current large model handles the table conversion well. What matters far more is the quality of your input and your review pass. Do not switch models hoping for better test cases when the real problem is a thin PRD.

Can I paste our internal PRD into a public chat tool? Check your company policy first. Many teams allow it only in an approved enterprise account with training turned off. If in doubt, remove customer names, revenue figures, and unreleased roadmap details before pasting.

How many test cases should one PRD produce? There is no right number. A small feature might need 15 good cases; a payments flow might need 120. Judge by risk coverage, not row count. A model that produces 200 rows is usually repeating itself.

Should the LLM write automated test code too? It can, but treat the generated code more carefully than the generated prose. Check that assertions can actually fail and that nothing important has been mocked away. Generated tests that always pass are worse than no tests.

Does this replace test design skill? No. It removes the typing, not the thinking. The value you add is the implicit rules, the cross-feature risks, and the judgement about what matters most — none of which appear in the document you pasted.