Test Coverage Planning
You can recite equivalence partitioning, boundary analysis, decision tables and state transition — and still freeze when someone hands you a real user story. Coverage planning is the missing skill: looking at a story and deciding which techniques to apply, in what proportion, driven by risk. It’s what turns a pile of techniques into one coherent plan.
1 The Hook
Maia had just finished the bootcamp. She could define equivalence partitioning in her sleep, draw a boundary table without looking it up, and explain a decision table to anyone who’d listen. Three weeks into her first QA job at a Wellington firm building a portal for a regional council, she was handed her first real ticket: “Test the new KiwiSaver-style contribution form — members can set a contribution percentage and a start date.”
She opened the form and started typing. She put in 5%, it worked. She put in 10%, it worked. She tried a date next month, it worked. She tried a couple of weird percentages like 7.5%, fine. After half an hour of poking at values she felt she’d had a good go, wrote “tested, no issues found,” and moved on. The form went live.
Two weeks later a member set their contribution to 0% — a perfectly reasonable thing to do when pausing contributions — and the system happily accepted it, then later divided by that zero when projecting their balance and threw an error that locked them out of their account. A whole class of bug, around the lower boundary and the “pause” business rule, that Maia never went near. She knew boundary value analysis. She just never decided to use it here.
Her team lead, Hemi, didn’t reach for a bug-tracking lecture. He sat down with the same story and, in about ten minutes, sketched a coverage plan on a whiteboard. “What are the inputs? A percentage — that’s a number with a range, so boundary analysis: 0, the minimum allowed, the maximum, just over. A start date — partition it: past, today, future, far future. Is there a rule about pausing? That’s a condition — worth a row in a little decision table. Now — which of these would hurt most if it broke? The percentage, because it touches people’s money. So that’s where the boundaries go.” Every test Maia had missed fell straight out of that ten-minute plan.
That plan — not any one technique — is what this lesson teaches. The techniques are the easy part. Knowing which to point at a given story, and how hard, is the part that separates a junior who has memorised a toolbox from one who can actually test.
2 The Rule
Knowing a technique is not the same as knowing when to apply it. A coverage plan is the bridge from techniques to actual testing — it maps each input and rule in a story to the right technique, at a depth set by risk. Without that plan you test by gut feel: effort gets wasted on low-risk corners and the high-risk ones get a few random pokes and a “looks fine.”
3 The Analogy
The full toolbox you never open.
Picture a builder who’s bought every tool going — a beautiful set, drill, level, stud-finder, the lot — and then hangs a heavy shelf using only the screwdriver because it’s the one already in their hand. The shelf goes up. It also comes down two weeks later, because the right job needed the stud-finder to hit a joist and the level to keep it straight. Owning the tools achieved nothing; choosing the right tool for each part of the job was the whole skill.
A junior tester who “just tries some values” is that builder with the screwdriver. The percentage field needed boundary analysis (the level), the date field needed partitioning (the right drill bit), the pause rule needed a decision table (the stud-finder to find the load-bearing case). A coverage plan is you standing back, looking at the whole job, and deciding which tool each part needs before you start drilling holes.
4 The Technique-Selection Map
The single most useful thing a junior can carry into a story is a mental map from the shape of an input to the technique that fits it. You don’t guess — you look at what kind of thing each input is, and the technique falls out almost automatically. Here is the map:
Distinct categories or groups (account type, region, membership tier, valid vs invalid format) → Equivalence Partitioning. Test one representative from each class instead of every value.
Combinations of conditions / business rules (“if member is over 65 AND balance > X then…”) → Decision Table. Lay the conditions out so no combination is missed.
Status or workflow changes (draft → submitted → approved; active → paused → closed) → State Transition Testing. Test the allowed moves and the ones that should be blocked.
A sequence of actions / end-to-end flow (register, verify email, log in, complete profile) → Use-Case / Scenario Testing. Walk the realistic journey a user actually takes.
Most real stories contain several of these at once. The KiwiSaver form had a number (percentage → BVA), a category-ish date (start date → EP), and a rule (pause behaviour → decision table). Recognising the shapes is how you know, on sight, that one story needs three different techniques — not one technique applied three times.
5 Building a Coverage Plan — Watch Me Do It
Let’s build a full plan on one user story, out loud, so you can see the thinking — not just the answer.
Step 1 — identify the inputs and rules. I read it and underline: amount (a number, $10–$5,000), payment method (three categories), pay-in-full vs instalment (a choice with conditions). And two rules: instalments only over $500; direct debit only with instalments.
Step 2 — pick a technique per input using the map.
Step 3 — decide depth by risk. Which of these would hurt most if it broke? The amount and the rules, because they touch money and eligibility — a wrong boundary could take the wrong amount, and a broken rule could let someone set up an invalid instalment plan. So I spend my boundary tests carefully there. The payment-method field is lower risk — one representative per type is plenty; I’m not going to test fifty card numbers.
Step 4 — list the resulting test cases. Boundaries on amount (6 cases). A decision-table row for each meaningful combination: $400 + instalment (should be blocked), $600 + instalment + direct debit (allowed), $600 + pay-in-full + direct debit (blocked — direct debit needs instalments), $200 + pay-in-full + credit card (allowed). One happy-path scenario end-to-end (enter amount, choose method, confirm, see receipt). That’s roughly a dozen targeted cases — far more coverage than an hour of random poking, and every case traces back to an input or a rule.
6 Risk-Weighting Coverage
Here is the idea that stops a plan from becoming a never-ending wall of test cases: not everything deserves equal depth. You have finite time. Spreading it evenly across every field is a quiet way of under-testing the dangerous bits while over-testing the harmless ones.
The driving question is simple: “where would a bug hurt most?” Spend your careful boundary analysis on the fields that move money, decide eligibility, or affect safety. Give a light touch — one or two representative cases — to cosmetic or low-consequence fields.
On the rates form: the amount field is high-risk (it’s money), so full boundary analysis. The eligibility rules are high-risk (a broken rule lets through an invalid plan), so a careful decision table. The method field is medium-risk — one case per type. A purely cosmetic field like an optional “reference note” box is low-risk: check it accepts text and doesn’t fall over on something empty, and move on. You wouldn’t run a six-point boundary analysis on a note field while the money field gets two random values — yet that’s exactly the inversion an unplanned tester drifts into.
Risk-weighting is also how you answer “have you tested enough?” honestly. “Enough” isn’t a number of test cases — it’s having matched your depth to the risk of each part. A small, sharp plan that hammers the money field and lightly touches the note field is better coverage than a hundred cases spread blindly across both.
7 Common Mistakes
🚫 Applying one favourite technique to everything
Why it happens: You’re most confident with boundary analysis (or whatever you learned last), so every field becomes a boundary problem.
The fix: Read the shape of each input first and let the map choose the technique. A category field doesn’t want boundaries; a rule doesn’t want a partition. Match the tool to the input, not to your comfort zone.
🚫 Spending equal effort everywhere
Why it happens: Treating every field as equally important feels fair and thorough.
The fix: It isn’t thorough — it’s unfocused. Ask “where would a bug hurt most?” and pour your depth into the money, eligibility and safety fields. Light touch on the cosmetic ones is not laziness; it’s good prioritisation.
🚫 Testing only the happy path
Why it happens: Valid inputs work, the screen looks right, and it feels “done.”
The fix: The happy path is the one path that’s least likely to be broken. Your plan must include boundaries, invalid inputs, and the blocked combinations — that’s where the bugs live. Maia’s 0% bug was one step off the happy path.
🚫 Confusing “lots of test cases” with “good coverage”
Why it happens: A long list of test cases looks like hard work and feels reassuring.
The fix: Fifty tests on the easy field and none on the risky one is bad coverage with a big number on it. Coverage is about which inputs and rules you’ve exercised and at what depth — not the count. A tight dozen targeted cases can beat a hundred random ones.
🚫 Never writing the plan down
Why it happens: “It’s all in my head” feels faster than sketching it out.
The fix: A plan in your head can’t be reviewed, handed over, or pointed to when someone asks what you covered. Three lines on a card — input, technique, risk — takes a minute and makes your testing visible, repeatable, and defensible.
8 Now You Try
Three graded exercises. Write your answer, run it for AI feedback, then compare to the model answer.
For the story below, list each input/field and the rule, and for each one name the technique that fits its shape and a one-line justification. Use the selection map.
A member can place a hold on a book. They enter the number of items to hold (1 to 10). They choose a pickup branch from a list (Central, Newtown, Karori, Miramar). A hold has a status that moves: requested → ready → collected, or requested → cancelled. Rule: members with overdue items cannot place a hold.
List each input/rule, the technique, and why:
Show model answer
Number of items (1-10): Boundary Value Analysis — it's a number with a range, so bugs cluster at the edges (0, 1, 10, 11). Pickup branch: Equivalence Partitioning — four distinct categories; one representative test per branch is enough. Hold status flow (requested → ready → collected / → cancelled): State Transition Testing — it's a workflow of statuses; test allowed moves AND blocked ones (e.g. collected → ready should be rejected). Overdue rule (members with overdue items can't place a hold): Decision Table — it's a condition that gates the action; lay out overdue vs not-overdue against "hold placed?" so the rule is explicit. Marking: full marks correctly match each input's SHAPE to its technique (number→BVA, categories→EP, status flow→state transition, condition→decision table) and give a short why for each. A common miss is calling the branch list "boundaries" or skipping the state-transition nature of the status flow.
For the story below, draft a small risk-weighted coverage plan: which technique for each input, a High/Medium/Low risk label, and the resulting test cases — with the most depth on the highest-risk part.
A user books tickets for a council event. They enter a quantity (1 to 8 tickets). They pick a ticket type (adult, child, concession). They add an optional note for the organiser (free text). Rule: concession tickets require the quantity to be 4 or fewer. Children under-quantity are free but still count toward the total.
Draft your plan (input → technique → risk → cases):
Show model answer
Quantity (1-8) — Boundary Value Analysis — risk: HIGH (drives the total and the concession rule). Cases: 0, 1, 8, 9, plus 4 and 5 because the concession rule pivots there. Ticket type (adult/child/concession) — Equivalence Partitioning — risk: MEDIUM. Cases: one booking per type. Note (free text) — light touch — risk: LOW. Cases: normal text accepted; empty note accepted; doesn't break on a long/odd input. No deep effort here. Concession/quantity rule (concession requires qty ≤ 4) — Decision Table — risk: HIGH. Cases: concession + qty 4 (allowed), concession + qty 5 (blocked), adult + qty 5 (allowed — rule doesn't apply). Where the depth goes: the quantity field and the concession rule, because they decide eligibility and the total. The note field gets a couple of cases and no more. A plan that boundary-tests the note box while giving the rule one happy case is upside down. Marking: full marks assign a defensible technique per input, a risk label per input, and concentrate the deepest testing (boundaries + rule combinations) on the high-risk quantity/rule rather than the cosmetic note field.
The test plan below is lopsided: nearly all the effort sits on a trivial field while the high-risk one is barely touched. Critique it and rebalance it — say what’s wrong, then redistribute the depth toward the risk.
Existing plan (lopsided): “Display name: test empty, 1 char, 50 chars, 100 chars, max length, emoji, spaces only, leading space, trailing space, special characters, very long string, name with numbers (12 cases). Amount: enter $50, check it works (1 case).”
Critique and rebalance:
Show model answer
What's wrong: The plan is inverted. The display name is a low-risk, optional cosmetic field and gets 12 cases; the amount is the high-risk field — it's money AND it has a $1,000 tax-receipt rule — and gets a single happy-path poke. There's no boundary analysis on the amount, no test of the receipt rule at all, and "lots of cases" on the name has been mistaken for good coverage. Rebalanced plan: Display name — risk: LOW — Equivalence Partitioning / light touch: normal name accepted, empty accepted (it's optional), one odd-input case (very long / special chars) so it doesn't crash. ~3 cases is plenty. Amount — risk: HIGH — Boundary Value Analysis: $4.99, $5, $5.01, $9,999.99, $10,000, $10,000.01. Plus the rule boundary: $1,000 and $1,000.01. The $1,000 receipt rule — risk: HIGH — Decision Table / boundary on the rule: $1,000 (no receipt or receipt? confirm intended), $1,000.01 (receipt triggered), a large amount (receipt triggered). Make the rule's boundary explicit. Marking: full marks (a) name the inversion — depth on the cosmetic field, almost none on the money/rule field, and "many cases ≠ good coverage"; (b) cut the name field to a light touch; (c) move boundary analysis onto the amount AND test the $1,000 receipt rule, which the original ignores entirely.
9 Self-Check
Click each question to reveal the answer.
Q1: What is a coverage plan, and why isn’t knowing the techniques enough on its own?
A coverage plan maps each input and rule in a story to the right technique, at a depth set by risk — it’s the bridge from knowing techniques to actually testing. Knowing EP or BVA in the abstract doesn’t tell you which one to point at a given field; the plan is the decision step that the techniques alone don’t give you.
Q2: An input is a number with a minimum and maximum — which technique, and one with a fixed list of categories?
A number with a range → Boundary Value Analysis (bugs cluster at the edges). A fixed list of distinct categories → Equivalence Partitioning (one representative per class). Reading the shape of the input is how you choose.
Q3: A story has a workflow of statuses (active → paused → closed) and a combined business rule. Which techniques?
The status workflow → State Transition Testing (test allowed moves and blocked ones). The combined business rule → Decision Table (lay out the conditions so no combination is missed). One story, two techniques — that’s normal.
Q4: What single question decides how much depth each field deserves?
“Where would a bug hurt most?” Money, eligibility and safety fields get your careful boundary analysis and rule combinations; cosmetic, low-consequence fields get a light representative touch. Depth follows risk, not habit.
Q5: Why is a tight dozen targeted cases often better coverage than a hundred random ones?
Because coverage is about which inputs and rules you’ve exercised and at what depth — not the count. A hundred cases piled on an easy field while the risky one goes untested is a big number hiding a real gap; a small plan matched to the risk covers what matters.
10 Interview Prep
Real questions asked in NZ QA interviews for junior roles. Read the model answers, then practise your own version.
“I hand you a user story for a registration form. Walk me through how you decide what to test.”
First I read it and underline every input and every “if/then” rule. For each input I ask what shape it is and let that pick the technique: a number with a range gets boundary value analysis, a fixed set of categories gets equivalence partitioning, a status flow gets state transition, and combined business rules get a decision table. Then I weight by risk — I ask “where would a bug hurt most?” and put my deepest testing on the money, eligibility or safety fields, with a lighter touch on cosmetic ones. The output is a short coverage plan: input, technique, risk, and the resulting cases — so anyone can see what I covered and why.
“How do you know when you’ve tested enough?”
“Enough” isn’t a number of test cases — it’s whether my depth matches the risk of each part of the feature. If the high-risk fields — the ones touching money or eligibility — have their boundaries and rule combinations covered, and the low-risk cosmetic fields have a representative case or two, then I’ve covered what matters. I’d rather have a tight, risk-weighted plan than a huge pile of cases spread blindly, because a hundred tests on an easy field can still leave the dangerous one untested.
“You learned several test design techniques in training. How do you choose between them on a real task?”
I match the technique to the shape of the input rather than reaching for my favourite. Ranges and numbers point me to boundary analysis; distinct categories to equivalence partitioning; combinations of conditions to a decision table; workflow or status changes to state transition; and an end-to-end journey to scenario testing. Most real stories need two or three of these at once, so the skill isn’t the technique itself — it’s reading the story, recognising the shapes, and building one coherent plan that uses the right tool for each part.