Writing Good Test Cases

Chapter 4 taught you to choose the checks; this topic teaches you to write them down so they survive contact with reality. A test case is a designed check written so that anyone — a colleague, a new hire, you in six months — can run it the same way and judge the result the same way. Writing them well is a craft with visible failure modes, and it's the single most common take-home task in junior QA hiring, so we're going to do it properly: one real case, built in full, then broken twice so you can see exactly how cases go wrong.

Think of a recipe. Ingredients you need before starting, numbered steps, and a photo of what the dish should look like. A recipe that ends with "cook until done" has a specific, nameable problem — and so do most bad test cases, as you're about to see.

The Anatomy

A test case has four load-bearing parts. The title — one line that says what's being checked, specific enough to find in a list of two hundred: "SUMMER15 applies 15% to a 3-night stay for a non-member." The preconditions — everything that must be true before step one: logged out, a property with availability, the promo code active. Preconditions are where "works on my run, fails on yours" goes to die. The steps — numbered actions, each one concrete: search, select, enter, click. And the expected result — what exactly should happen, precise enough that two people can't disagree about pass or fail. Teams add extras — priority, a link to the story (that's traceability, two topics ahead) — but these four are the skeleton of every test case ever written.

The Worked Example

Here's the SUMMER15 criterion from Chapter 2 — "15% off, 3+ nights only" — turned into a full case, boundary-flavored per Chapter 4:

The Expected Result Is the Test

Now watch the case break — first way. Same title, same steps, but the expected result reads: "the discount is applied correctly." Run it: the total shows $258.00. Pass or fail? Who knows — "correctly" lives in someone's head, and the head isn't in the document. This is the "cook until done" recipe, and it's the number-one rookie flaw: a vague expectation isn't a smaller test, it's no test — the comparison at testing's heart needs both sides written down. The rule from Chapter 2 applies with full force: if two people could disagree about pass/fail, it's not an expected result yet. $255.00 is a verdict machine; "correctly" is a shrug.

Granularity: One Case, One Check

Second way to break it. Imagine TC-118 grew: apply the promo, then also log in to check the member interaction, then also cancel to check the refund math, then... — a 40-step mega-case checking six things. It fails at step 12. Now what? The five checks after step 12 never ran — blocked behind the failure — and the run report says "TC-118: fail," which tells nobody which of six behaviors broke. Atomic cases fail independently and report precisely; mega-cases fail once and hide everything behind the wreck. The professional rule: one case verifies one thing. Six checks means six cases — sharing preconditions is fine, sharing verdicts is not.

Written for a Stranger, Built to Last

Two last habits separate cases that survive from cases that rot. First, write for a stranger — someone with your product access but not your head. "Do the usual setup" means nothing in six months, to a new colleague, or to you-in-January; the preconditions exist so the case carries its own context. Second, specify behavior, not pixels. "Select dates giving 3 nights" survives Lucy's date-picker redesign; "click the third cell in the calendar's second row" dies with the old layout — and multiplied by two hundred cases, that death is a maintenance crisis. Anchor steps to what the user does, not to where the button lived on the day you wrote the case. Cases written for strangers, at behavior level, are the ones still paying rent two years later — and, not incidentally, the ones automation can be built from without rewriting (Chapter 9 will collect that debt).