How to write test cases from requirements: a 7-step method with examples

To write test cases from requirements, split the document into single testable requirements, list the conditions each one must satisfy, design positive, negative, boundary and integration cases for each condition, and write every case with preconditions, steps, test data and one expected result, linked to its requirement ID. The seven steps below turn that into a repeatable method, with a worked example you can copy.

Test scenario vs test case: what is the difference?

A test scenario is what to test; a test case is exactly how to test it. "Coupon codes at checkout" is a scenario. "Apply the expired code WINTER25 to a $60 cart and expect the error 'This coupon has expired'" is a test case. Scenarios help you plan coverage. Test cases are what actually runs.

Step 1: Extract testable requirements

Read the PRD, spec or user story and pull out every statement that describes behaviour. Rewrite each as one sentence that could pass or fail.

PRD excerpt:

Shoppers can enter a coupon code at checkout. Valid codes apply their discount. Unknown or expired codes show an error and do not change the total. Some codes need a minimum cart value of $50.

Testable requirements:

• REQ-103: A valid coupon applies its discount at checkout.
• REQ-104: Invalid or expired coupons are rejected with an error, and the total does not change.
• REQ-106: Coupons with a minimum cart value only apply at or above that value.

Step 2: List the conditions for each requirement

A condition is anything that changes the outcome. For REQ-104: unknown code, expired code, empty input, code with extra spaces, lowercase version of a valid code. Write them down before designing tests. This is where most missed bugs hide.

Step 3: Pick test categories

For each condition, decide which categories apply:

• Positive: valid input, expected success.
• Negative: invalid input, expected, graceful failure.
• Boundary: values at the exact edges (a $49.99 cart, a $50.00 cart).
• Integration: the requirement working with other parts (the discount still applies after a cart update).

Our guide to positive, negative and boundary test cases covers each category with more examples.

Step 4: Define test data

Name the exact data each case uses: codes (SAVE20, WINTER25, SAVE99), cart values ($49.99, $50.00), user accounts. Vague data ("an invalid code") produces tests that pass by accident.

Step 5: Write each test case with the template

Field	Example
ID	TC003
Title	Reject expired coupon WINTER25
Requirement	REQ-104
Category	Negative
Preconditions	Signed-in shopper, cart total $60.00, WINTER25 expired yesterday
Steps	1. Open checkout. 2. Enter WINTER25 in the coupon field. 3. Click Apply.
Test data	Code: WINTER25
Expected result	Error "This coupon has expired" appears; total stays $60.00

Rules that keep test cases useful:

• One expected result per case. If you need "and also", you probably need a second case.
• Steps a stranger could follow. No "apply the usual code".
• Expected results you can observe. "Works correctly" is not observable. "Total shows $48.00" is.

Step 6: Link every case to its requirement

Put the requirement ID on every test case. That link is what lets you build a requirements traceability matrix, spot untested requirements and explain which requirement a failure breaks.

Step 7: Review for gaps

Before you run anything, check:

• Does every requirement have at least one negative case?
• Are numeric limits tested exactly at the edge and one step either side?
• Is anything in the PRD ambiguous? Write it down and ask. Ambiguity found here costs a message. Found in production, it costs an incident.

Worked example: the finished set for the coupon requirements

ID	Title	Req	Category
TC001	Apply valid coupon SAVE20, expect 20% off	REQ-103	Positive
TC002	Reject unknown coupon code SAVE99	REQ-104	Negative
TC003	Reject expired coupon WINTER25	REQ-104	Negative
TC004	Coupon at minimum cart value ($50.00) applies	REQ-106	Boundary
TC005	Discount survives a cart update	REQ-103	Integration
TC006	Coupon at $49.99 is rejected with the minimum-value message	REQ-106	Boundary

Using AI to draft test cases (with a prompt)

Language models are good at step 2 and step 3: listing conditions and proposing cases across categories. Use them for a first draft and review the output. A prompt that works:

You are a senior QA engineer. From the requirement below, write test cases in a table with:
ID, title, category (positive / negative / boundary / integration), preconditions, steps, test data, expected result.
Rules: one expected result per case; exact test data; test numeric limits at the edge and one step either side;
list any ambiguity in the requirement as open questions instead of guessing.
Requirement: <paste one requirement and its acceptance criteria>

Two cautions: a model will confidently invent behaviour the PRD never mentions, so check each expected result against the source; and a chat window has no memory of your other requirements, so keep IDs and links yourself.

How testdart does this end to end

testdart runs this method as a product. You give Project Brain your spec, PRD, user stories or Jira issues, and it extracts the requirements. AI Genie generates test cases for the requirements you pick, across the categories you choose, with an optional instruction to steer it. Each case stays linked to its requirement, runs in a real Chrome browser, and lands in a report that explains every failure. It is one workflow described in our overview of AI-native QA. Try it on your own PRD: start free.

FAQ

How many test cases does a requirement need? Enough to cover each condition at least once, with at least one negative case. Simple requirements may need two or three; requirements with numeric limits or many input types need more.

Should test cases include UI details like button names? Include what a tester must interact with and what they must observe. Avoid details that change often (exact layout) unless the requirement is about them.

Can I write test cases before the feature is built? Yes, and you should. Writing them from the requirement first exposes ambiguity while it is still cheap to fix.