Stop 10 · Testing & User AcceptanceTopics · 2/8

Writing Test Cases From Requirements

In short

Every requirement you write is a promise. A test case is how someone checks the promise was kept. Writing a few yourself makes your requirements sharper, because gaps jump out fast.

Translating a documented requirement into specific test scenarios and expected outcomes — a direct extension of Phase 3's skill in writing clear, testable requirements.

The purple blob writes on paper with a red pen at a desk stacked with blank answer sheets.

Think of it like this

The paper setter's answer key

A good exam paper setter writes each question with a model answer and marking scheme. If she can't write a clear answer, the question is badly worded. Test cases are the answer key for your requirements, and they expose fuzzy ones just as quickly.

Watch it happen

Boundary tests for 'free delivery on orders of ₹499 or more'

498

499

500

5000

1/5One rule, five order totals. Good test cases aim at the edges, where bugs love to hide.

The big ideas

What you need to know

Steps and expected result

Each case has preconditions, steps, test data and one expected result. Anyone should get the same outcome.

Test the edges

Check values just below, on and just above every limit. Off-by-one mistakes are very common.

Negative cases

Test what shouldn't work too: wrong OTP, expired card, missing field. Users will try all of these.

Link to requirements

Tag each case with its requirement ID so you can see what's covered and what isn't.

See it in code

Walk through the code

text

1ID:       TC-DEL-032Req:      REQ-12 Free delivery on orders >= ₹4993Pre:      Logged-in customer, Pune address4Steps:    1. Add items totalling ₹4995          2. Go to checkout6Expected: Delivery fee shows ₹0, total is ₹4997Result:   Pass / Fail

1/3A unique ID and a link to the requirement it proves.

One test case, aimed at the exact boundary. It links back to the requirement, so coverage is easy to check.

Save yourself the pain

Common mistakes

Oops

Writing only happy-path cases where everything goes right.

Do this instead

For each rule, add at least one boundary case and one negative case.

Oops

Expected results like 'works correctly'.

Do this instead

State exactly what appears: the message, the amount, the status, the email sent.

Your mission

Write ten test cases

~35 min

Quick check

The rule is 'passwords must be 8 to 20 characters'. Which set of lengths tests it best?

Go deeper

1Write 3-5 test cases derived from a requirement you documented in Phase 3.
2Learn to include both positive (happy path) and negative (error/edge case) test scenarios.
3Practice tracing each test case back to the specific requirement it validates.