How are test cases derived from a user story?
A user story ("as a customer I can pay with a saved card so that checkout is faster") becomes testable through its acceptance criteria: each criterion, written as a precondition, an action and an observable result, maps to at least one test case, and the questions the story does not answer — a declined card, an expired one, no saved card at all — become the negative cases. The story's benefit clause ("so that") says what to measure; the role says which permissions to test with. A story with no acceptance criteria is not ready for testing, and usually not for development either.
Read the guide: How to Write Test Cases
How to use AI Requirement → Test Cases
- Paste the requirements — numbered (REQ-1, 2.3 …) or free text.
- Choose how many test cases you want (5 to 40) and the output language.
- Press Generate. The tool first splits the text into atomic requirements, then writes cases that each cite the requirements they cover.
- Check the traceability matrix for requirements without a case, then download the cases as CSV, Markdown or JSON.
AI Requirement → Test Cases features
- Splits requirements into numbered atomic rules
- Structured test cases mapped to requirement IDs
- Traceability matrix (requirement → test cases) generated automatically
- Markdown, CSV and JSON export
AI Requirement → Test Cases example
Requirements → cases
Input:
REQ-1 Admin can delete a lookup value.
REQ-2 Referenced values cannot be deleted.Output:
TC-001 (REQ-1) Delete unused value succeeds
TC-002 (REQ-2) Delete referenced value is rejected with reference count
…Frequently asked questions about AI Requirement → Test Cases
How is traceability handled?
Each requirement keeps your document's own number, or gets REQ-1, REQ-2 … when it has none, and every test case lists the requirement IDs it covers. The traceability matrix shows at a glance which requirements have no case.
What if a requirement cannot be tested?
The tool says so in the summary instead of inventing a case for it — for example a statement of intent with nothing observable to check. Rewrite it as a measurable rule and generate again.
Should I use this or Requirement → Test Scenarios?
Use this one when you need executable cases with steps and expected results tied to requirement IDs. Use Requirement → Test Scenarios first when you want to agree on end-to-end coverage at a higher level.
Technical notes
The result lists every requirement it found — with your document's own numbering when it has one, otherwise REQ-1, REQ-2 … — and up to 40 test cases, each with steps, test data, an expected result, a priority, a risk rating and the IDs of the requirements it covers. A requirement that cannot be tested is named in the summary rather than silently skipped.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.