Write test cases a stranger could run

Yesterday you turned four acceptance criteria into one-line test ideas and wrote the refinement questions that fill the gaps. Today those ideas become test cases a stranger could run.

A question is not a test case, and neither is a one-line idea. A test case is written so that a stranger could run it and know, with no judgment calls, whether it passed. The shape:

ID:        NB-SIGNIN-003
Title:     Verify that a wrong password shows a clear
           error and does not sign the shopper in
Steps:     1. Go to /practice/tumble-kitchen/
           2. Enter demo@tumblekitchen.test in Email
           3. Enter WrongPass99! in Password
           4. Click Sign in
Expected:  An error appears saying the email or password
           is wrong. No success message. Not signed in.

Notice three things. The title starts with “Verify that” and states both the condition and the expected outcome, so the case is readable from the title alone. The steps carry exact data, a real email and a real wrong password, never “enter invalid credentials”. And the expected result is specific enough to disagree with. “Something sensible happens” is not an expected result; it is a shrug.

The three qualities of a case worth keeping

• Atomic. It tests one thing. When it fails, you know exactly what broke, with no untangling.
• Repeatable. Same steps, same result, every run, on anyone’s machine. Exact data is what makes this possible.
• Traceable. You can say which story or criterion it covers, so nobody ever asks why the case exists.

Those three qualities are what separate a case a stranger can run from a note to yourself.

One question becomes many cases

Now watch a single question expand. On Day 2 you asked what happens when credentials are wrong. That one question produces at least five cases:

• Verify that a wrong password shows the error and does not sign in.
• Verify that a wrong email shows the same error, worded identically.
• Verify that an empty password shows the length rule, not the wrong-credentials error.
• Verify that the error clears once the shopper fixes the input and signs in.
• Verify that the password field never displays the typed password in plain text.

Six questions from Day 2, each expanding like that, plus one case per acceptance criterion, plus the missing-criteria questions you raised. A three-line story just produced twenty to thirty honest test cases. The count is not the goal, the coverage is, but this is why “it is only a sign-in” is never true.

Workflow

1. Criterion or question
2. Verify-that title
3. Exact data
4. Result you can disagree with

Do this today

Write five full test cases for the sign-in story, in the shape above: Verify-that titles, exact data in the steps, expected results specific enough to disagree with. Then run each one through my Test Case Builder; it scores your case against the qualities above and shows you exactly what to tighten. Rework until all five score clean, and keep them, because they are the spine of your capstone next week.

One of your five cases needed a password of a specific length, and you probably picked that length by feel. Tomorrow you learn to pick it by technique, because the right six values do the work of sixty.