ChatGPT Test Case Prompt: What to Specify and Where It Breaks
A good ChatGPT prompt for test cases names four things: the requirement text itself, the coverage you want (happy path, negative, boundary), the exact output format, and what the model should do when the requirement is unclear. Leave any of them out and the model fills the gap with a guess, which is why "write test cases for a login page" returns twelve plausible rows that nobody can import or run.
The prompt matters because the model never refuses. Give it half a requirement and it writes a complete-looking set anyway, with invented limits and invented error messages. Someone reading fast sees well-formed cases and approves them. The prompt is the only place you get to tell it to stop and ask instead.
What should the prompt contain?
Here is a template that works the same way in ChatGPT, Claude, or any chat model:
You are writing test cases for a QA team.
Requirement (paste the exact text, with its ID):
R-014: A user can reset a password by email. The link expires after 30 minutes
and works once.
Write test cases that cover:
- the main flow
- negative cases (invalid input, expired or reused link)
- boundary values for any number in the requirement
Output a table with these columns, nothing else:
ID | Title | Preconditions | Steps (numbered) | Expected result | Requirement ID
Rules:
- One expected result per case, observable without asking me what you meant.
- Use only facts stated in the requirement. If a limit, role, or message is not
stated, do not invent it. List each such gap under "Questions" after the table.
Each part earns its place:
| Part of the prompt | What it prevents |
|---|---|
| The requirement pasted verbatim, with an ID | Cases based on what the model assumes a "password reset" does |
| Named coverage categories | A set made entirely of happy paths |
| A fixed column list | Steps buried in prose that cannot be imported into TestRail or Zephyr |
| "One expected result, observable" | Expected results like "the system works correctly" |
| "Do not invent, list questions" | Made-up limits, error strings, and roles |
| A Requirement ID column | Cases you cannot trace back when the spec changes |
Where does the output still break?
Invented specifics. Even with the instruction above, a model sometimes writes "error message: Invalid email format" when the requirement never said what the message is. Read every expected result against the source text, and treat any exact string or number that is not in the requirement as a question.
Duplicates that differ by one word. Ask for boundary cases on a 30-minute expiry and you may get "expires at 30 minutes", "expires after 30 minutes", and "link is invalid at 30:01" as three rows. Merge them. A suite padded with near-copies costs execution time and hides the cases that matter.
Steps that cannot be executed. "Verify the system handles the load" is not a step. Check that every step is something a tester can do with their hands and that the expected result is something they can see.
Silence on what the spec left out. The model covers what the text states. It does not know that your product also has an SSO login that bypasses the reset flow. Domain knowledge stays with you.
Drift across a long document. Paste forty requirements into one prompt and the later ones get thinner cases, with IDs that slip or repeat. Work in batches of five to ten, and keep the same prompt for every batch so the columns stay identical.
When is a prompt not enough?
Once you do this weekly, the prompt becomes a process you maintain: the template, the example case in your team's format, the batching, the check that every requirement ID appears at least once in the output, the export to a file your test management tool accepts. All of that is repeatable, and it is the part worth turning into a tool instead of a document people copy from.
The review is not repeatable in the same way. Somebody has to decide whether the cases would catch the rule being broken, and no prompt moves that decision off your desk. For the reasoning behind that, see reviewing AI-generated test cases. Casely packages the repeatable half: attach the requirements file, approve a test plan, and get cases in your own columns and ID scheme as an Excel file that imports cleanly.