The way testers think (and why it works)

Yesterday you used Tumble Kitchen like a shopper. Today you stop being a shopper.

Picture a demo of a checkout that “worked”. Card in, order placed, confirmation shown. The happy path is clean, so the room relaxes. Now picture the same checkout with a name like O’Brien, apostrophe and all, or an address with a hash sign in it. That is where a lot of real checkouts fall over. Real names, real addresses, real people have punctuation in them. The demo did not.

Testers look at working software and feel curious instead of relieved. On every feature, two questions:

1. What is this feature promising the user?
2. Where can that promise break?

Finding the promises

A promise is anything the product claims, in words or by implication. Open Tumble Kitchen and read it like a contract. The promises are sitting in plain sight:

• The search is labelled “Search the menu”, so searching “patty” should find the Baked Cheese Patty and nothing pretends otherwise.
• Every price is shown in JMD, so every total should be too.
• The discount note says IRIE20 gives 20% off orders of 10,000 JMD or more. That sentence is a precise promise, and precise promises are where testers earn their pay.
• The sign-in says the password must be 8 to 64 characters. Another precise promise.
• The cart badge shows a count, so the count should always match what is in the order.
• Delivery costs 500 JMD and goes free at 15,000 or more. Two more numbers, two more promises.
• The shop even publishes its own rule book: open the “House rules” panel on the page. That panel is a requirements document, exactly like the ones real teams write, and everything in it is testable.

Every one of those promises is a test waiting to be written. That is where test cases come from. Not from imagination, and not from a template. From reading.

Where promises break

Once you have a promise, push on it:

• What if the input is empty?
• What if it is very long?
• What if the user does the steps out of order, or twice?
• What if the network is slow, or drops halfway?
• What happens with real data, not tidy demo data?

You are not being paranoid. You are being honest about the fact that real users are messier than the demo.

Workflow

1. Read the promise
2. Ask where it breaks
3. Try the messy path

Habits that get you there fast

• When you read a requirement, underline the words should, must, and always. Those are the promises. Each one is a test.
• When someone says “it works”, ask “how do you know?” Because “works” usually means “worked once, on my machine, on the happy path”.
• When a test passes, ask what it actually proved. If the answer is “not much”, that is a weak test.

Do this today

Ten minutes, on the store. Write down every promise Tumble Kitchen makes. Aim for at least eight; the five above are a start, not the full list. Keep the list somewhere you can find again, because over the next three days you turn it into written test cases, and later this week one of those promises turns out to be broken.

If you want to see where this thinking leads as a career, my interactive QA Career Roadmap starts at exactly this stage. Have a look at stage one; it is the map for everything this course touches.