Can an LLM write test cases from requirements?

Yes, and it is one of the better uses of a model in testing, because the requirement supplies the oracle from outside the code. The catch is that requirements are usually incomplete, and the model resolves the gaps silently rather than flagging them — so ask for its assumptions and its questions as separate outputs.

Why are generated test cases sometimes confidently wrong?

Because an ambiguous requirement still produces a fluent answer. Where the text does not specify a boundary, the model picks a reading and writes cases for it, and the output gives no sign that a choice was made.

How should generated test cases be reviewed?

Per requirement rather than per document, so batches stay small enough to actually read, and with the expected results written or confirmed by a person. Inputs and scaffolding can be generated safely; the assertion carries the intent and is the part worth the reviewer's time.

Forge · 16 September 2026

Turning requirements into test cases with an LLM: what actually breaks

Generating test cases from a written requirement works well until the requirement is ambiguous, which is most of the time. What the model does with the gaps, and how to structure the work so it surfaces them instead of filling them.

3 min read

A written requirement is an oracle expressed in prose, which is why generating test cases from one is the most defensible use of a model in quality engineering: the source of truth is external to the code. The difficulty is that requirements are rarely complete, and a model does not stop at the edge of what it was told.

Ambiguity gets resolved silently

"The user can withdraw up to their available balance" does not say what happens at exactly the balance, whether a pending transaction reduces it, or what occurs when the balance is zero. A person reading that asks. A model produces confident cases for one reading of it, and nothing in the output marks the choice as a choice.

Illustrative proportions, not measured — they depend almost entirely on how precisely the requirement was written. The category worth designing for is the last one, which is the only part that improves the requirement rather than the suite.

Make the model report, not decide

The single change that makes this work is asking for the ambiguities as an output alongside the cases, rather than hoping none were encountered. A model is good at noticing that a requirement does not specify the boundary; it is only bad at telling you unprompted.

01Ask for the assumptions it had to make, as a separate list, before you look at the cases at all.
02Ask for the questions it would put to the author. These are usually the real defects, found before any code was written.
03Generate cases per requirement, not per document. A batch of forty gets skimmed; a batch of four gets read.
04Keep the expected result in the reviewer's hands. Inputs and structure can be generated; the assertion is the part that carries the intent.
05Feed confirmed answers back into the requirement, not just into the test. Otherwise the next person regenerates the same ambiguity.

What it does not do

It does not know which paths carry the money. Coverage of a requirement is not coverage of the risk in it.
It does not know what the system already does elsewhere, so it will happily specify behaviour that contradicts a neighbouring feature.
It does not reduce the review burden proportionally. Ten times the cases is ten times the reading, and unreviewed generated cases are worse than no cases — they carry the authority of a test without the evidence of one.

Used as a drafting tool that surfaces what the requirement failed to say, this is among the most useful things a model does in engineering. Used as a way to arrive at a large suite quickly, it produces a suite that is confidently wrong in exactly the places nobody thought to check.

Common questions

Can an LLM write test cases from requirements?: Yes, and it is one of the better uses of a model in testing, because the requirement supplies the oracle from outside the code. The catch is that requirements are usually incomplete, and the model resolves the gaps silently rather than flagging them — so ask for its assumptions and its questions as separate outputs.
Why are generated test cases sometimes confidently wrong?: Because an ambiguous requirement still produces a fluent answer. Where the text does not specify a boundary, the model picks a reading and writes cases for it, and the output gives no sign that a choice was made.
How should generated test cases be reviewed?: Per requirement rather than per document, so batches stay small enough to actually read, and with the expected results written or confirmed by a person. Inputs and scaffolding can be generated safely; the assertion carries the intent and is the part worth the reviewer's time.

What AI changes about software testing, and what it does not

AI generates tests quickly, but generated tests assert current behaviour, which encodes existing bugs as expected. Where AI genuinely reduces QA effort, where the oracle problem stops it, and how to tell the two apart.

4 min read

When to use an AI agent, and when a script is the right answer

Agents are chosen for task complexity when the deciding factor is input variance. Where each one belongs, why an agent's failures are harder to catch than a script's, and the hybrid that usually wins.

4 min read

All insights.

Browse insights Talk to us

Or write to us at [email protected]