How to Write Prompts That Generate Reliable Test Scenarios

The pitch for prompt-driven test generation is simple enough to be suspicious: describe what you want tested and get a working end-to-end test back. It does work, and it works more often than sceptics expect — but the failure mode is real, and it is almost always the same one. A vague prompt produces a test that runs green while proving nothing.

This guide is about closing that gap. It is not about clever phrasing or model-specific tricks; those change every few months. It is about the information a test-generation system genuinely needs from you, why each piece matters, and how to correct a result that came back wrong.

What the system already knows, and what only you know

A generation system connected to your application can see the pages, the controls, the routes and the states. If you connect a repository, it can also see components, handlers and data models. It does not need you to describe any of that — and when you do describe it, you tend to describe it slightly wrong and lead the generation astray.

What it cannot see is intent. It cannot know:

• Which of the four ways into checkout is the one that matters to you.
• That "success" means the card is charged exactly once, not that a confirmation page appeared.
• That your discount codes stack with loyalty credit but not with each other.
• That a seat-limit breach should block the invite rather than silently queue it.

Everything in that list is a business rule or a judgement. That is the payload of a good prompt. The rest is noise.

The four parts of a reliable prompt

1. The actor and their starting state

"A user" is the most common source of ambiguity in test prompts. Which user? Signed in or anonymous? With what history?

❌ A user checks out. ✅ A returning customer with one saved Visa and an empty cart checks out.

Starting state determines which path the product takes. Naming it removes the largest single class of "the test did something unexpected" results.

2. The goal, in business terms

Say what the actor is trying to accomplish, not the route they take to it.

❌ Click Cart, then Checkout, then Apply Code. ✅ Checks out a £40 cart using a 20% discount code.

Routes change. Goals rarely do. Describing the route also silently narrows the test to today's navigation — if the flow later gains a one-click path, a route-shaped test keeps exercising the old one.

3. The distinguishing condition

This is what makes the scenario different from its siblings, and it is where most of the real coverage lives.

A returning customer checks out with a card that expired last month. An admin invites a teammate when the seat limit is already reached. A subscriber upgrades mid-cycle, so the charge is prorated.

Without the condition you get the happy path every time, which is the path least likely to be broken.

4. The outcome that proves it

This is the part teams leave out most often and regret most. If you do not say what success looks like, generation falls back on generic assertions — no error banner, page rendered, HTTP 200 — that pass happily while the business rule underneath is wrong.

✅ …and is charged £32 plus tax, exactly once, with the discount shown as a separate line on the confirmation.

Name the state that must hold at the end: amounts, counts, statuses, records created, emails queued. If a human would check it before signing off a release, put it in the prompt.

Putting it together

Weak prompt	Strong prompt
Test the login page.	A user who has enabled two-factor authentication signs in with a valid password and a valid code, and lands on their dashboard with an active session.
Test checkout.	A returning customer with a saved Visa checks out a £40 cart using a 20% code, and is charged £32 plus tax once, with the discount itemised on the confirmation.
Check that invites work.	An admin at their seat limit invites a new teammate; the invite is refused with an upgrade prompt, no seat is consumed, and no invitation email is sent.
Verify password reset.	A user requests a password reset and opens the link 25 hours later; the link is rejected as expired, the old password still works, and no session is created.

The strong prompts are not longer because of padding. Every clause removes a decision the system would otherwise have to guess.

What to leave out

Selectors, IDs and CSS. These are the most fragile information you can supply, and supplying them defeats the purpose: a system that resolves elements against the live application adapts when they change, while a hardcoded selector reintroduces exactly the maintenance burden you were trying to escape. This is the same failure that makes traditional suites brittle — see Flaky Tests: Why E2E Suites Break.

Step-by-step click sequences. If you write the steps, you have written the test case by hand and used a language model as a transcriber. Worse, you have locked in today's navigation.

Multiple unrelated checks. "Test checkout and also verify the account page and the email templates" produces one long test that fails for three unrelated reasons and tells you nothing precise. One prompt, one path.

Implementation vocabulary. Table names, endpoint paths, feature-flag names. Unless the check is genuinely about the API contract, describe the user-visible outcome instead.

Refining a scenario that came back wrong

When the generated scenario is not what you meant, the instinct is to edit the steps. Resist it — an edited step is a manual patch that will be lost the next time the scenario is regenerated. Correct the intent instead, and let the scenario be rebuilt from the corrected description.

Three common corrections:

It picked the wrong path. Add the starting state or entry condition you left implicit. "Start from the product page, not the saved cart."

Its assertion is too weak. Name the outcome explicitly. "Passing requires the card to be charged exactly once — check the payment record, not just the confirmation page."

It over-reached. Narrow the scope. "Only cover the refusal at the seat limit; the upgrade flow is a separate scenario."

Each of these is a sentence about behaviour. None of them require knowing how the test is implemented, which is the point: the prompt stays the artifact your team maintains and reviews, and the implementation underneath is free to change.

Reviewing what comes back

Generation gets you a draft quickly, which makes it tempting to approve quickly. Three checks before you do:

1. Could this test pass while the feature is broken? The most common defect in a generated test is a weak assertion. If the only check is "no error appeared", it will pass a silently wrong total.
2. Could this test fail while the feature is fine? Timing assumptions, hardcoded dates and dependence on shared mutable data create failures that train your team to ignore red builds.
3. Does it test one thing? A test that can fail for four unrelated reasons is a test whose failure you will have to debug before you can act on it.

These are the same questions you would ask reviewing a colleague's test code. The review is faster now, but it has not become optional — and it is the step that keeps confirmed failures meaningful rather than noisy.

Where this leaves the QA role

It is worth being direct about what changes. Writing steps, hunting selectors and repairing tests after a redesign are being automated away, and they were most of the hours. What remains is the part that was always the actual skill: knowing what could go wrong, what it would cost, and what evidence would prove it did not happen.

That is a shift in leverage, not a reduction in importance — a QA engineer who can articulate precise, well-chosen scenarios now produces coverage in an afternoon that used to take a sprint. We wrote more about the trajectory in How AI Is Changing the Role of QA Engineers.

Where BuniOD fits

BuniOD takes exactly the kind of prompt described here. You connect your application, write a sentence about the flow you want covered, and it returns a complete end-to-end scenario — steps resolved against your real interface, the test data it needs, and assertions that check the outcome you named. You read it back in plain English before anything runs, and refine it by replying with another prompt rather than editing generated code.

From there the scenario is maintained for you: it adapts when the interface changes, runs on every release, and reproduces suspected failures before anyone is alerted. Your prompt stays the source of truth, which is why it is worth writing well.

Conclusion

Prompt-driven test generation is reliable in proportion to how much intent your prompt carries. Name the actor and their starting state, state the goal in business terms, include the condition that makes this path distinct, and — above all — say what outcome proves success. Leave out selectors, click sequences and implementation detail; those are the parts a connected system derives better than you can.

When something comes back wrong, correct the description rather than the steps. The prompt is the artifact you keep, and a well-written one produces a test that is still meaningful long after the interface it exercises has been redesigned twice.

Try it on a flow of your own — request access and write one sentence.