A test case prompt tackles the slowest step after a requirements review: everyone understands the feature, yet once you sit down to write cases, the happy path flows while boundary values and error situations quietly go missing, only to resurface as bug reports after handover. The prompt below fixes the case categories, the table columns and the way expected results must be written before you paste anything in, so what comes back is a table you can execute directly or import into a test management tool.
When this prompt fits
Use it to draft cases before a new feature enters testing, to rebuild a regression list after a redesign, or to check acceptance criteria as a product manager. It needs one clearly written requirements passage: a prototype note, a section of a spec, or a user story all work. If all you have is a one-line verbal request, first expand it into a short paragraph covering background, entry point, rules and limits; the output quality drops sharply without it.
The prompt, ready to copy
You are a software test engineer with 8 years of experience. Based on the requirements below, design a set of test cases that can be executed as written.
Requirements: {{requirements}}
Extra context: {{extra context, such as the pages or APIs involved, account roles, data limits; write "none" if there is none}}
Output rules:
1. Output a table with these columns in order: case ID, case title, preconditions, steps, test data, expected result, priority, case type.
2. Case types must cover four groups: normal flow, boundary values, errors and invalid input, permissions and roles, with at least 3 cases in each group.
3. Boundary cases must state concrete numbers, such as a length cap, an amount cap or a submission limit; do not just write "enter the maximum value".
4. Expected results must be checkable: name the exact message shown, the data change or the state change; do not write vague lines like "works normally".
5. After the table, add a separate section titled "Questions the requirements leave open", listing every ambiguity one by one; do not invent rules to fill the gaps.
Output the table first, then the open questions, with no long introduction before the table.How to fill the two variables
- {{requirements}}: paste the requirements text in full, including business rules, field limits and state transitions. The more specific, the better. If you only write "build a coupon feature", the model can only guess from generic e-commerce rules, and the guessed cases will not match your real rules.
- {{extra context}}: state what testing actually has at hand, such as which account roles exist, whether ready-made test data is available, and whether the feature runs in an app or a browser. Role information matters most, because every permission case is generated from it.
What a filled run looks like
Swap the requirements for one short passage, "users can edit their delivery address; the address text is capped at 100 characters; province, city and district are all required; the new address takes effect immediately after saving", and the returned table contains rows like these:
| ID | Title | Test data | Expected result | Type |
|---|---|---|---|---|
| TC-04 | Save an address of exactly 100 characters | An address of exactly 100 characters | Saving succeeds and the list page shows the full address | Boundary |
| TC-05 | Save an address of 101 characters | An address of 101 characters | Saving is blocked with a length-limit message | Boundary |
| TC-09 | Save without selecting a district | Province and city selected, district empty | Focus moves to the district field with a required-field message | Errors |
Rows carrying concrete numbers like these mean the prompt is working. If every title reads like "verify saving works", repeat rules 3 and 4 with emphasis and run it again.
Follow-ups when the result disappoints
- Cases too shallow: ask "keep only the high-priority cases and add a negative check to each one: how the system should block deliberately wrong input".
- Repeated submissions missing: add "the same user may click save several times in a row" to the extra context, then ask for a "repeated actions" group.
- You want automation: ask "rewrite the high-priority cases as Playwright test steps, with locators and assertions for each".
One last note: AI-generated cases work well as a first draft and a gap checklist. Cases touching payments, permissions or data deletion still need a human tester to run them one by one in the real environment before release, and the ambiguities listed under the open questions are usually exactly the points nobody in the review meeting had thought through.
