Test Case Generation Prompts: How to Write Explicit Steps

The pitch for prompt-driven test generation invites short prompts: describe what you want tested and get a working test back. In practice, the test case generation prompt that runs reliably is not short. It is an explicit, numbered list of steps, written the way you would brief a new manual tester: which button, which field, which value, how long to wait and what to check before moving on.

That is not a step backwards. You still write no selectors and no code. You write what a good manual test case already contains, and the system does the part that used to need an engineer: finding each element on the live page and turning your steps into a scenario that can run every day.

This guide covers how to structure the steps, where test identities, files, waits and checks go, how to state an expected result that can fail, and the common mistakes. The examples use BuniOD's format, but most of the advice applies to any tool that runs plain-language steps.

Test case generation using AI: what the model does with your steps

A test generation system works through your steps in a real browser. For each step it finds the element on the live page that matches what you wrote, such as the button labelled "Continue" or the field labelled "Email", and stores what it found so the scenario can run again later.

What it cannot do is make the decisions only you can make:

• Which of two "Continue" buttons you mean.
• Which account to sign in with.
• What to type into a field that accepts anything.
• How long a slow action takes on your staging server.
• What "done" looks like: a URL, a message, a row in a table, an email.

If the prompt leaves one of these open, the model has to guess. A guess can work today and fail tomorrow on the same build, and that is the kind of failure teams learn to ignore.

The parts of a test case generation prompt

A BuniOD scenario starts from a start URL and two plain-language fields.

The task is the prompt: a numbered list of steps, often grouped into short sections with comment lines such as // Log in first. Each step is one action or one check.

The expected result is one or two concrete things you can observe at the end: the final URL, a message on the page, a value in a table, an email in a test inbox.

The steps say how to get through the flow; the expected result says what proves it worked. Good steps with a vague expected result produce a scenario that runs to the end and proves nothing.

How to write the steps

Group the steps into sections

Split a long flow into the parts a tester would name, such as log in, do the action and check the result, with a comment line above each group, as in the full example below. The prompt is easier to review, and a failure is easy to place: step 9 was in the upload, not the login.

One action per step, with the label as it appears on the page

Write each step as one action and use the exact text the page shows. If the button says "Sign in", write "Sign in", not "Log in" or "the login button".

Vague	Exact
Open the uploads	Click on "Uploads" in the main menu
Enter the number of pages	Set the value of the "Pages per letter" field to "2"
Submit it	Click on the "Upload 1 file" button
Check that it worked	Confirm you see the text "1 file ready to upload"

If the same label appears twice on the page, say which one you mean in words a person would use: "the 'Continue' button under the password field".

Give the values to type

A step that says "fill in the form" leaves every value to chance. Put the value in the step, such as Fill in the "Reference" field with "TEST-1042", and choose it on purpose: an ordinary value for the main path, a boundary value when the boundary is what you are testing.

Use a test identity for logins and email

Never put a real person's email address or password in a prompt. Create a test identity, a named test user with an email address, a password and any custom fields your app needs, and refer to it by name:

2. Fill in the email from "Test Customer" into the "Email" field
4. Fill in the "Password" field with the password from "Test Customer"

A test identity also has its own test inbox, so a step can open the emails your application sends, such as a confirmation or a password reset link. "An email is sent" becomes something the scenario checks rather than assumes.

Attach files for upload steps

If the flow uploads a document, attach the file to the scenario and refer to it in the step, together with the text the upload area shows: Upload the attached letters.docx file to the upload area with the text "Drop files here". Use a small test file, never a real customer's document, and keep it the same from run to run.

Write waits as steps

A person waits without thinking about it; a scenario waits only when told to. After any slow action, such as a payment, a file being processed or an email being sent, add an explicit step such as Wait for 30 seconds. Choose a wait that covers a slow day on staging, not a good one. Martin Fowler's Eradicating Non-Determinism in Tests names asynchronous behaviour among the common causes of tests that pass one day and fail the next, and a missing wait is exactly that.

Add "Confirm …" checks between steps

Write checks as steps that start with "Confirm":

7. Confirm the url is https://staging.example.com/upload
10. Confirm you see the text "1 file ready to upload"

Each one becomes a check in the scenario. If the login failed silently, the run stops at the check after it with a clear reason, instead of failing five steps later on a button that is not on the page. Good places for checks are after logging in, after filling in a form and after anything slow.

How to write the expected result

Write one or two concrete things a person could see at the end, and that would be wrong if the feature were broken: a URL, visible text, a value or an email. Each line below is a separate example; one scenario needs only one or two:

The url is https://staging.example.com/orders/overview?success=true (extra query params don't matter)
The page shows the heading "Order confirmed"
The "Recipients" column of the newest job shows "2"
The inbox of "Test Customer" has an email with the subject "Your order"

Avoid "it works", "the upload succeeds" or "no errors". They describe a feeling, not an observation, and they pass while the feature is broken: an order total that is wrong by one line item still "works". The "Confirm …" steps check the way there; the expected result checks where you ended up.

A full example

Here is a complete prompt for a document upload flow on an anonymised staging site, starting from its home page.

// Log in first
1. Click on the "Sign in" button
2. Fill in the email from "Test Customer" into the "Email" field
3. Click on "Continue"
4. Fill in the "Password" field with the password from "Test Customer"
5. Click on "Continue"
6. Wait for 2 seconds
// Upload the file
7. Confirm the url is https://staging.example.com/upload
8. Upload the attached letters.docx file to the upload area with the text "Drop files here"
9. Set the value of the "Pages per letter" field to "2"
10. Confirm you see the text "1 file ready to upload"
11. Click on the "Upload 1 file" button
12. Wait for 30 seconds
13. Confirm the table of uploaded jobs shows "2" in the "Recipients" column

Expected result: The newest row in the table of uploaded jobs shows the file name "letters.docx"

Why it is written this way:

• Steps 2 and 4 take the credentials from the "Test Customer" test identity, so no real person's details appear in the prompt.
• Steps 6 and 12 are waits: a short one after logging in, a long one while the server processes the file.
• Step 7 checks that the login landed on the upload page before anything is uploaded.
• Steps 10 and 13 check the way through, including the result of processing, not just that a button was clicked.
• The expected result names one thing that would be wrong if the upload had failed.

There are no selectors or code in it: every step is something a person could do by reading the screen. The flow creates a new job on every run, which is fine because the app accepts the same file twice. If yours creates something that must be unique, see the mistakes below.

Common mistakes

Vague steps. "Log in" hides five actions and a choice of account; "fill in the form" hides every value. Write the steps out, one action each.

Labels that do not match the page. "Click Submit" when the button says "Upload 1 file" leaves the model to decide what you meant, and a close match can be the wrong element. Copy labels from the screen, and update the step when a label is renamed.

Missing waits. A step that runs before the page is ready fails for reasons unrelated to the feature. If a scenario fails on a step that works when you try it by hand, lengthen the wait before it.

A vague expected result. "It works" cannot fail in a useful way. Name the URL, the text, the value or the email that proves it.

Personal data instead of a test identity. A real email address or password ends up in run logs and screenshots, sends mail to a real inbox and breaks when its owner changes the password.

Flows that create the same record every day. A scenario that signs up with the same email, or creates a project whose name must be unique, passes once and fails on the next scheduled run because the record already exists. End the flow by deleting what it created, or work on a record that already exists. If a run fails before the clean-up steps, remove the leftover record by hand.

Several flows in one prompt. One long scenario that checks the upload, the billing page and the profile fails for three unrelated reasons. Keep one flow per prompt. When flows depend on each other, such as signing up before resetting a password, run them in order as a business process, which skips the later ones when an earlier one fails.

What to leave out

Selectors, IDs and CSS. Write what a person sees. Each step is matched against the live page, and a hardcoded selector brings back the maintenance work that makes traditional suites brittle. See Flaky Tests: Why E2E Suites Break.

Implementation vocabulary. Table names, endpoint paths and feature-flag names are not on the page. Describe the visible result instead.

Reviewing the scenario before it runs

Nothing runs until a person confirms the scenario. Read it against your prompt and ask three questions:

1. Could it pass while the feature is broken? Look for a missing check or a loose expected result.
2. Could it fail while the feature is fine? Look for missing waits, a label that matches two elements, and data that will not survive a second run.
3. Does each step do what you meant? A step aimed at the wrong element is easier to spot now than after a week of red runs.

If something is wrong, fix the prompt: make the step exact, add the wait or the check, and regenerate. A wrong value can be corrected directly as an input value. If the agent asks a question because a step is unclear, answer it, then put the answer in the prompt so the next regeneration does not need to ask. The review is faster than reviewing test code, but it is not optional: it is what keeps failures meaningful rather than noisy.

Where this leaves the QA role

Writing test code, hunting for selectors and repairing locators after a redesign are being automated away. What remains is what manual testers were always good at: writing steps a stranger can follow, choosing test data on purpose and knowing what evidence proves a flow worked. More on that shift in How AI Is Changing the Role of QA Engineers.

Where BuniOD fits

BuniOD takes exactly the kind of prompt described here. You add your web app's start URL, write the task as explicit steps and add the expected result. BuniOD works through the steps in headless desktop Chromium, matches each step to a real element on the live page and turns the prompt into a runnable scenario: the "Confirm …" lines become checks, and the expected result becomes the final checks. A person reviews and confirms the scenario before it runs, and can edit input values or regenerate it from an updated prompt. When something is unclear, the agent asks a question instead of guessing.

Confirmed scenarios run on demand or once a day at a time you set. Test identities supply logins and a test inbox, attached files feed upload steps, and business processes run dependent scenarios in order. If an element moves and its stored locators miss, AI matching finds it again and the new location is saved after a passing run. Each run keeps screenshots, console and network logs and a plain-language explanation of any failure. BuniOD does not run in CI pipelines or on mobile browsers, so it fits best as a daily check of your critical web flows.

Conclusion

A test case generation prompt works when it leaves nothing to guess. Write the task as numbered steps in short sections, with labels as they appear on the page, the values to type, a test identity for logins and email, attached files for uploads, waits after slow actions and "Confirm …" checks along the way. Then state one or two concrete things that prove the flow worked.

That is more than a one-line request and far less than a coded test, and it is a skill testers already have: a clear manual test case is most of a good prompt. When a scenario comes back wrong, fix the step in the prompt and regenerate, so the prompt stays the artifact your team keeps and reviews.

Try it on a flow of your own — start free and write the steps for your first flow.