Generate Test Cases from Requirements: A Step-by-Step Workflow
Generating test cases from requirements means reading a requirements document (a PDF, a DOCX, a spreadsheet of user stories) and deriving, for every testable statement in it, the cases that would prove the statement true and the cases that would catch it being false. The output is a list where each case has a title, preconditions, steps, and an expected result, and each one points back at the requirement it came from. Done by hand it takes a few days for a mid-sized spec. Done with a generator it takes an afternoon, and most of that afternoon is review.
The part people underestimate is the middle. A requirements document is written for stakeholders, so rules sit inside paragraphs, limits sit in footnotes, and the same behavior gets described twice in two sections with slightly different numbers. Nobody can generate good cases from that text, a person or a model, until someone has pulled the rules out into a flat list. Skip that step and the cases cover whatever the reader happened to notice.
What do you need before you start?
Three things. The document itself, in a form you can search: a scanned PDF with no text layer has to go through OCR first, and checking that tables survived extraction takes two minutes and saves an hour later. A glossary, even a rough one, because "account", "user", and "customer" often mean three different things in one spec. And one example of a test case your team already wrote, so the new cases match your columns, your ID scheme, and your tone instead of arriving in a format someone has to rewrite.
Free and open sourceCasely writes these cases for youAttach a spec and one file of your team's existing test cases in Claude. Casely copies your columns, names the gaps it found in the spec, and exports a single Excel file your tracker imports in one pass.Read the install docsThe six steps
- Split the document into atomic statements. One rule per line. "The user can reset a password by email, and the link expires after 30 minutes" is two statements: the reset flow and the expiry. Give each a requirement ID (R-014, R-015) as you go, because every later step refers back to it.
- Mark what is testable and what is not. A statement with a number, a state change, or a visible outcome is testable. "The system should be fast" is not, and it goes on a separate list of questions for whoever wrote the spec. The phrases that signal an untestable requirement are worth learning to spot on sight.
- Pick a technique for each statement. The statement's shape decides it (table below). A numeric range gets boundary values. A set of rules that combine gets a decision table. A multi-step flow with states gets a state transition model.
- Write the cases. Each case needs preconditions, numbered steps, and one expected result that someone could check without asking you what you meant. Write the negative cases in the same pass as the positive ones, not as an afterthought.
- Trace every case to a requirement. A case with no requirement is either testing something undocumented (worth a question) or padding. A requirement with no case is a gap in the suite.
- Review the set as a whole. Look for duplicates, for statements covered only by the happy path, and for requirements that got one case when the rule has an edge on both sides.
| What the statement looks like | Technique | Cases it usually produces |
|---|---|---|
| A numeric limit or range ("between 8 and 64 characters") | Boundary value analysis | Below, at, and above each edge |
| Groups of inputs treated the same ("any supported file type") | Equivalence partitioning | One case per group, plus one invalid group |
| Several conditions combining into one outcome | Decision table | One case per rule column |
| A flow with states ("draft, submitted, approved") | State transition | Each valid transition, plus the forbidden ones |
| Many independent options that interact | Pairwise combinations | A reduced set that covers every pair |
The techniques themselves are covered in equivalence partitioning vs boundary value analysis and decision tables and state transition testing.
Where does this process fail?
The document is wrong or incomplete. Cases derived faithfully from a spec that contradicts itself are faithful to the contradiction. The most useful by-product of step 1 is usually a list of questions: a limit stated as 30 minutes in one section and 60 in another, an error state nobody described, a role that appears in a table and nowhere else. Send those back before you test, not after.
Implied behavior never makes it onto the page. Specs rarely say that a deleted record should disappear from search, or that a double click should not submit twice. A person with domain experience adds these. A generator only adds what the text supports, which is why a generated set tends to be tidy and shallow.
Volume hides weak cases. A spec with 80 rules and five cases each is 400 cases, and nobody reads 400 cases carefully. Review by requirement, not by case: for each ID, ask whether the cases together would catch the rule being broken in either direction.
What is worth automating?
Steps 1, 4, and 5 are mechanical once the rules are written down: splitting a document into statements, applying a technique to a statement, and keeping the requirement-to-case mapping straight across hundreds of rows. A generator does them well and does not get tired at row 300. Steps 2 and 6 are judgment: deciding that a statement cannot be tested as written, and deciding that a suite is deep enough for a feature that handles money.
Casely follows this order. You attach the PDF, DOCX, or XLSX, approve one test plan, and get the cases back as a TestRail-ready Excel file, with a Postman collection when the document is an API spec and a list of the gaps it found while reading. The review step stays with you, which is where it belongs.