# 1 · Plan: what "working" means to them You know how the thing was built, so you'll test how it was built. A QA person starts from the other end: what the person asked for, what they'll do with it, and what would hurt if it broke. A few minutes of planning decides whether the rest of your testing finds anything. --- ### T1 · Write down what "working" means to the person **Rule:** Before you test anything, write what "working" means in the person's words, from the brief, the ticket or the conversation: what they'll do, and what they'll see when it works. One line for a small job; a short list for a feature. Each line is something you could watch happen ("I can pay with a saved card and get an email with the receipt"), not a quality ("payments are robust"). **Why:** If you don't write it down, you test against your memory of the code. The person's idea of "working" usually includes something the code doesn't do yet, and that's the bug they'll find on day one. **Agent trap:** writing the list from the code you just read: "the `applyDiscount` function returns the new total". The brief said "the discount shows on the basket page before checkout", and the basket page still shows the old price because it reads a cached total. **Check:** read each line aloud as the person. Could they say "yes, that's what I meant"? Does every line describe something a person does or sees? ### T2 · Test what was asked, not what was built **Rule:** Put the ask and the build side by side. Go through the ask line by line and mark each part: built, built differently, or missing. Test the parts that were built differently or missing as hard as the rest. They're the most likely to be wrong, and the least likely to have tests. **Why:** Tests written by the person who built the feature cover what they built. Whatever they misread or forgot is missing from the code and the tests alike, so everything passes and the person finds the gap. **Agent trap:** the brief asked for "export to CSV and to Excel". You built CSV, wrote three good tests for it, and reported "export works". Excel was never built and nothing in the tests mentions it. **Check:** every line of the ask appears in your plan, marked built, different or missing. Anything marked different or missing goes in your report, even if you fixed it. ### T3 · Start where it would hurt most **Rule:** Before listing test cases, list what would hurt a person most if it broke: losing their work or their data, being charged wrongly, being locked out, seeing someone else's data, a message going to the wrong person. Test those first and most. Cosmetic details come last. **Why:** Time runs out before cases do. If you test in the order you built, the payment step gets the same five minutes as the tooltip, and the bug that costs someone money ships. **Agent trap:** spending the session on layout and label checks for a new settings page, and never trying "delete account", the one control on the page that can't be undone. **Check:** name the two or three worst things that could happen with this work. Each one has a test or a manual try in your plan, near the top. ### T4 · Map what else this change could break **Rule:** Before testing, find what shares code with the change: other screens that use the same component, other callers of the changed function, anything that reads the same data, settings or styles. Add the most used of them to your plan as regression checks (checks that what worked before still works). **Why:** A person doesn't care that the new page works if the old one they use every day broke. Breakage in a neighbour is the bug nobody looks for, because nobody changed that screen. **Agent trap:** changing the shared `` to fix the booking form, testing the booking form, and never opening the invoice page, which uses the same picker and now saves dates a day early. **Check:** search for every user of what changed: ``` git diff --name-only git grep -n "DatePicker" -- 'src/' ``` List them. Pick the ones a person uses most and add them to the plan. **Limit:** you don't need to retest everything. A change to one function with two callers needs two checks, not a full pass of the product. ### T5 · Test with data that looks like theirs, somewhere safe **Rule:** Test with data shaped like real use: real-looking names and addresses, a realistic number of items, the sizes and languages the product will meet. Test in a local or test environment, with test accounts and the payment or email provider's test mode. Never use real people's data in a test, and never send real messages or payments to make a test work. **Why:** Tidy sample data hides the bugs real data brings. Real customers' data in a test can leak, get changed, or trigger an email they never expected, and that is a harm in itself, whatever the test found. **Agent trap:** testing a mailing feature with the first five rows of the production customer table, so five real customers get a test email. Or testing the order list with three orders named "test", when the shop has four thousand and the page takes eight seconds to load. **Check:** where did your test data come from, and where would a message or payment go? If either answer involves a real person, stop and switch to a test account, test mode or made-up data. ### T6 · Write the plan as a checklist the report will fill **Rule:** For a large job, write the plan as a short checklist before you start: the "working" lines (T1), the ask against the build (T2), the risks (T3), the neighbours (T4), and the explore and automate checks you'll do. As you test, mark each item: passed, failed (with a bug, D1), or not tested (with why). The filled checklist becomes your report (H2). **Why:** Without a list, testing drifts to what's easy to test, and at the end you can't say what you didn't cover. The person needs that gap to decide whether to ship. **Agent trap:** testing in a stream of whatever comes to mind, then writing "tested thoroughly" because it felt thorough. A minute later you can't say whether you ever tried the empty state. **Check:** before reporting, does every item on the plan have a mark? **Limit:** a small job needs no written plan. One line for "working" and one for the neighbour you checked is enough (see the size table in `START.md`). --- ## Summary checklist - [ ] "Working" written in the person's words, as things they do or see. - [ ] Every line of the ask marked built, different or missing. - [ ] The worst things that could break are named and tested first. - [ ] Neighbours that share the changed code are listed; the most used are in the plan. - [ ] Test data looks real and belongs to nobody; messages and payments go nowhere real. - [ ] Large job: a written checklist, marked as you go.