A new spec lands as a PDF on Monday. By Wednesday you have to hand over test cases in your team's TestRail format: their column names, their priority values, their ID scheme. You spend two days copying requirement text into rows, and the import fails anyway because one header reads Expected Result instead of Expected result.
So you paste the spec into ChatGPT or Claude and ask for test cases. You get rows of happy path, each with "Verify the feature works correctly" as the expected result, in columns nobody on your team uses.
Your prompt skipped the work a QA lead does before writing a single case. This guide gives you that work as five prompts you can paste into any AI chat today. No tool to install.
Step 1. Give the AI your format, not just the spec
Attach two files: the requirements, and a file with two or three test cases your team already wrote. The example teaches the AI more than any description of your format.
I'm attaching (1) the requirements for the Payments module and (2) three test
cases in my team's format.
Before anything else, describe the format of file 2: the exact column names in
order, the allowed values for Priority and Type, the ID scheme and the last ID
used, and the writing style of steps and expected results. Don't write any test
cases yet.
Check the answer. If it lists High / Medium / Low and your team uses Blocker / Critical / Major / Minor, correct it now. Every case inherits this.
Step 2. Ask for a plan and the gaps, not the cases
This step decides what gets tested at all.
Read the requirements for the refund flow. Don't write test cases yet.
Give me:
1. A coverage plan: the areas you'll cover, the test design technique for each,
and an estimated number of cases.
2. A list of gaps in the spec, each with the section number and one concrete
question for the analyst. Look for: requirements with no measurable outcome,
sections that contradict each other or a worked example, error paths that are
never described, terms used as conditions but never defined, and external
services whose failure is not specified.
End by asking me to approve or change the plan.
A spec that says "refunds should be processed quickly" has no testable outcome. A limit of $50,000 in one section and a worked example of a successful $75,000 refund in another is a contradiction someone has to resolve before you can write the boundary cases. "Silent on the error path" is the most common gap: the success flow fills a page, and nobody wrote what happens when the payment provider times out.
Approve the plan, or cut it down. Then move on.
Step 3. Make the AI use real test design techniques
Without explicit techniques, generated suites drift to whatever the spec mentions first: ten variations of the happy path. Name the techniques in the prompt:
Plan approved. Write the test cases using:
- Equivalence partitioning: one case per group of inputs that behave the same.
- Boundary values on both sides of every edge. For a limit of 50,000 that means
49,999, 50,000 and 50,001, not just the rejected value.
- A decision table wherever an outcome depends on several conditions: one case
where all conditions pass, plus one case per condition failing on its own.
- State transitions: the allowed ones, and a case proving each forbidden one is
rejected.
- Error guessing: empty and max-length input, double submit, session expiry
mid-flow, network failure between request and response.
Use exactly the columns, values and ID scheme from step 1, continuing from the
last ID.
The "both sides of every edge" line matters. A suite with 50,000 and 50,001 but no 49,999 proves the limit rejects. It never proves the system accepts everything up to the limit, so an off-by-one that moved the limit down would pass.
Step 4. Review the cases against a quality bar
Ask the AI to grade its own output before you read it:
Review every case against these rules and fix the ones that fail:
1. Atomic: one behaviour per case. If the title needs "and", split it.
2. Independent: it sets up its own preconditions.
3. One deterministic expected result with values, e.g. "Balance decreases by
$500 and the history shows a refund with status Completed". No "works
correctly", no "either X or Y".
4. Concrete data in the steps: "Amount: 50,001", not "an amount over the limit".
5. Steps are actions; checks go in the expected result.
6. No two cases test the same partition.
7. Every requirement in scope has at least one case. List any that have none.
Rule 3 protects the tester who runs the case. A case whose expected result reads "the operation ends in created or pending" can't be marked pass or fail. A real fork in behaviour means two cases. An undecided spec is a gap for the list.
Step 5. Export a file TestRail can import
Ask for a CSV with your exact headers:
Export all cases as CSV. Use the headers from step 1, exactly as spelled, in the
same order. One row per case. Put each step on its own line inside the cell, not
as "<br>" or "\n" text. Quote every field.
Two things break imports: a header that differs by one character from your field mapping, and multi-line steps that arrive as literal <br> tags. Open the file in a spreadsheet and check both before you import it into TestRail, Qase, Zephyr or Xray.
Where the prompts start to hurt
The five prompts work. After a few sprints, these four things get old:
- You re-describe your format every new chat, and the model forgets a column halfway through a long suite.
- It writes cases before you approve the plan unless you stop it every time.
- The gap list depends on how carefully you phrased step 2 that day.
- The CSV still needs a manual pass for headers and line breaks.
That's why I packaged the workflow as Casely, a free, open-source skill for Claude Code, claude.ai, Cowork, the Claude desktop app and Codex. You attach the spec (or name a Jira issue or a Confluence page) and one example file, and say what you need:
"Here are the requirements for the Payments module and two example test cases my team writes. Give me test cases for the refund flow."
Casely runs the five steps above in one conversation and stops once, at the plan, for your OK. It copies your columns, priority values and ID scheme from the example file. It writes the cases with the techniques from step 3, then exports one .xlsx with your headers that TestRail imports in one pass, plus one Markdown file per case, or a UTF-8 CSV if your tracker wants one. Say yes once and it saves your team's style, so the next run needs no example file. When the spec describes an API, it also builds a Postman collection with every base URL, token and ID pulled out into variables, and no credentials in the file. When the spec names no endpoints, it asks for the API docs instead of inventing paths. In Claude Code, /casely:run then walks the UI cases in a browser, and /casely:bug turns a failure or a trace ID into a bug report in your team's format.
How do you know it finds the gaps?
The repo ships a benchmark: a fintech wallet spec with five planted defects (a vague "processed quickly", a $50,000 limit that contradicts a successful $75,000 example, a fee that is withheld but never sized, an undefined "verified status", and no behaviour for a payment provider outage), plus boundary rules, a state machine and a five-condition decision table. A 100-point rubric scores the run.
The first full run scored 85/100. It produced 33 cases continuing the team's ID scheme, matched all nine columns in order, and exported one workbook with no rejected case. It missed two of the five planted gaps. The rules that catch those two are now part of the skill. The spec, the example file and the rubric are in benchmark/, so you can score a run yourself.
Pick Opus for the plan phase if you can. Smaller models write acceptable cases from a plan they're handed, and miss the holes in the spec.
FAQ
Is there a free AI test case generator?
The prompts in this article are free with any AI chat. Casely is free and open-source under the MIT license; you pay only for the Claude or Codex plan you already use.
Can I import AI-generated test cases into TestRail?
Yes. Match the headers to your TestRail field mapping exactly and keep multi-line steps as real line breaks. Casely exports a file that already does both.
Does it work with requirements in other languages?
Casely writes the cases in the language of your example cases. A round-trip test checks that Arabic and Korean text, commas, quotes and line breaks survive the XLSX and CSV export cell for cell. A reader suggested the Korean case in the comments below.
What about scanned PDFs?
Text-based PDFs, DOCX and XLSX work well. An image-only scan may not extract cleanly, so export a text version when you can.
Add Casely to claude.ai, Cowork or the desktop app in one click from the Claude plugin directory. In Claude Code, paste this prompt:
Install the Casely plugin from https://github.com/JohnWayneeee/casely-qa-skill
Codex and manual setup are in the README.
More on how Casely came about: Your QA team was hired to find bugs. It spends two days a sprint formatting spreadsheets and Stop manually writing test cases.
If it saved you a day of formatting test cases, a ⭐ on the repo helps other QA engineers find it, and a coffee pays for the next release.
Top comments (4)
For the multilingual case, I would add a CSV round-trip check with Korean text, commas, quotes, and real line breaks. Matching headers alone will not catch damaged text or a step split into extra rows.
Does your benchmark check that the imported text matches the exported text exactly?
Great point — and I’ve also received feedback about Arabic text, so this is clearly not limited to Korean. I’ll add a CSV round-trip test covering Arabic, Korean, commas, quotes, and multi-line steps, then compare the re-imported values with the original test cases. Thanks for flagging it!
That should make the test much stronger. A useful Korean fixture is
메뉴판 주세요in a quoted cell with a comma and an actual line break; keep one untouched copy for the comparison.Will you also test the XLSX path against the same fixture?
Thanks, great suggestion! Yes, I’ll add 메뉴판 주세요 in a quoted cell with a comma and a real line break, and keep an untouched copy of the fixture for comparison.
I’ll also extend the same round-trip check to the XLSX path so both formats are covered.
I’d like to release this as a hotfix as soon as possible. If you have any additional recommendations specifically for Korean text or common CSV/XLSX issues in the Korean locale such as encoding, escaping, field order, or TestRail import behavior I’d really appreciate your advice.