Checklist-Based Testing
Structured lists of what to verify — built from experience, standards, and known failure modes. More flexible than formal test cases; more structured than ad hoc testing.
1 The Hook
A Dunedin team does an accessibility pass on a new council form before launch. Their best tester, who knows accessibility cold, runs it from memory. Looks great — ships. The next sprint a different person does the next form, also from memory, and forgets to check keyboard focus order. A screen-reader user files a complaint: they can’t tab through the form in a sensible order, so they can’t complete it.
The knowledge existed. It just lived in one person’s head and walked out the door the moment someone else did the work. There was nothing written down that said “check tab order follows the visual layout” — so on the form that mattered, nobody did. The fix wasn’t a smarter tester; it was a one-page list that every tester runs every time.
That list is checklist-based testing. It captures hard-won experience as a set of things to verify, so quality doesn’t depend on who happens to be testing today or what they remember under pressure.
2 The Rule
Capture what must be verified as a list of conditions — the what, not the how — so every tester checks the same things every time. It’s more flexible than scripted test cases, more reliable than testing from memory, and it must be kept alive as the product changes.
3 The Analogy
A surgical team’s pre-op checklist.
Before an operation at Auckland Hospital, the team runs a short checklist out loud: right patient, right site, allergies known, instrument count correct. These are experienced surgeons and nurses — they know all of this. The checklist doesn’t tell them how to operate; it just makes sure no critical item is skipped because someone was busy, tired, or assumed a colleague had it covered. It is the floor, not the ceiling, of safe practice.
A test checklist works the same way. It doesn’t script the tester’s every move — it names the conditions that must be verified so none slips through. Judgement and skill still do the work; the list just guarantees nothing important is forgotten.
What it is
A checklist is a list of conditions, questions, or items to verify. Unlike formal test cases, checklists don’t specify exact steps or expected results — they specify what to check, leaving the tester to determine how.
This flexibility makes checklists valuable when testing requires judgment (accessibility, UX quality, cross-browser compatibility) or when the exact steps can’t be scripted in advance.
Example checklists
| # | Check |
|---|---|
| 1 | Required fields marked with visible indicator |
| 2 | Required fields validated on submit — not mid-typing |
| 3 | Error messages are specific ("Enter a valid email address") not generic ("Invalid input") |
| 4 | Valid data accepted, form submits successfully |
| 5 | Field length limits enforced and communicated to user |
| 6 | Tab order follows visual layout, logical sequence |
| 7 | All labels correctly associated with their inputs |
| 8 | Successful submission provides clear confirmation |
| # | Check |
|---|---|
| 1 | Layout intact on Chrome, Firefox, Safari, Edge |
| 2 | No horizontal scroll on mobile (320px – 768px) |
| 3 | Touch targets ≥ 44px on mobile |
| 4 | Images load and aren’t stretched or cropped unexpectedly |
| 5 | Fonts render correctly — no invisible or fallback text |
| 6 | Navigation works at all breakpoints |
Maintaining checklists
A checklist is a living document. Every time you find a bug that wasn’t on the list, add it. When an item becomes irrelevant or is now covered by automation, remove it. Review and prune checklists at least once per release cycle.
At senior level, you should own and maintain checklists for your area. At lead level, you’ll have team-wide checklists that become the baseline quality standard.
Checklists vs formal test cases
- Checklists are faster to create and maintain. Good for experienced testers who know how to check the thing.
- Formal test cases are more precise. Required when tests will be re-run by different people, when compliance evidence is needed, or when automated.
- Many teams use checklists for exploratory and regression testing, and formal test cases for critical paths and audit trails.
ISTQB mapping
| Ref | Topic |
|---|---|
| 4.4.2 | Checklist-Based Testing — high-level conditions, structured but flexible |
| 4.4.2 | Checklists derived from experience, standards, requirements, and defect data |
Practice this technique: Try Grad Practice 07 — Team & about page, Senior Practice 01 — Accessibility audit.
4 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
Below are six lines someone added to a “login form” checklist. A good checklist item names what to verify and is judgeable; a bad one is either a scripted step, too vague to judge, or not a check at all. Mark each line good or bad and say why.
(b) Click the email box, type test@example.com, press Tab, type a password, click Submit
(c) The form works
(d) Error messages are specific, not generic
(e) Password field masks input by default
(f) Make it good
Show model answer
(a) GOOD — names a verifiable condition (visible required-field indicator); leaves the "how" to the tester. (b) BAD — that is a scripted test case (exact steps). A checklist names what to check, not the keystrokes; this belongs in a formal test case. (c) BAD — too vague to judge. "Works" how? Can’t be ticked objectively. (d) GOOD — a clear, judgeable condition (specific vs generic error messages). (e) GOOD — specific and verifiable (password masked by default). (f) BAD — not a check at all; meaningless. The rule: a good checklist item is the WHAT, is specific enough that two testers would agree whether it passed, and leaves the HOW to the tester’s judgement. Scripted steps and vague slogans both fail that test.
A team’s cross-browser checklist below has gone stale. One item is now handled by automation, one is no longer relevant, one is too vague, and a known bug type is missing. Rewrite the checklist: prune, sharpen, and add the missing item.
1. Layout intact on Chrome, Firefox, Safari, Edge
2. Page renders correctly in Internet Explorer 11
3. Unit tests pass in CI (now run automatically on every commit)
4. Looks fine on mobile
5. Fonts render correctly
Rewrite the checklist:
Show model answer
Revised cross-browser / responsive checklist: 1. Layout intact on current Chrome, Firefox, Safari, and Edge. 2. No horizontal scroll at mobile widths (320px–768px). 3. Touch targets are at least 44px on mobile. 4. Fonts render correctly — no invisible or fallback-only text. 5. Images load and aren’t stretched or cropped unexpectedly. What I removed: - IE 11 rendering — no longer relevant; IE is end-of-life and not in the supported browser set. - "Unit tests pass in CI" — now handled by automation on every commit, so it doesn’t belong on a manual checklist. What I sharpened / added: - "Looks fine on mobile" was too vague to tick — replaced with judgeable items: no horizontal scroll in a stated range, and a 44px touch-target minimum. - Added "images load and aren’t distorted" — a common cross-browser/responsive bug the original list missed. The point: a checklist is a living document. Prune what automation now covers or what’s irrelevant, sharpen anything you can’t objectively tick, and add new failure modes as you find them.
Build a checklist of 6–8 items for verifying a NZ government online payment form (e.g. paying a fine or a council rates bill). Make each item specific and judgeable, and include at least two NZ-specific conditions a generic checklist would miss.
Show model answer
NZ government payment-form checklist (example): 1. Required fields are marked and validated on submit, not mid-typing. 2. Amount is shown in NZD with a $ symbol and exactly two decimal places. 3. Error messages are specific enough for a user to self-correct (e.g. "Enter a 4-digit postcode"). 4. The form is keyboard-navigable and tab order follows the visual layout (accessibility). 5. NZ bank account in BB-bbbb-AAAAAAA-SS format is accepted; an invalid structure is rejected with a clear message. 6. A confirmation/receipt is shown after a successful payment, with a reference number. 7. The form meets the relevant NZ Digital Service Design / accessibility expectations (e.g. WCAG). 8. Content is available in te reo Māori where required, and names with macrons (e.g. Māori) display correctly. NZ-specific items: the NZD formatting, the BB-bbbb-AAAAAAA-SS bank-account format, macron/te reo handling, and alignment to NZ government service standards — all things a generic, overseas checklist would miss and that cause real failures here. The point: a good checklist names verifiable conditions (the what), stays judgeable, and is tailored to the actual context — including local rules a borrowed checklist wouldn’t contain.
Self-Check
Click each question to reveal the answer.
Q1: What does a checklist specify that a formal test case does not?
A checklist specifies what to verify — the conditions or questions — and leaves how to the tester. A formal test case specifies the exact steps and expected results. That makes checklists faster and more flexible, and formal test cases more precise and reproducible.
Q2: Why does the council-form story show the value of a checklist over testing from memory?
Because knowledge in one person’s head leaves with them, and even experts forget items under pressure. A written checklist that every tester runs every time makes quality independent of who is testing today and what they happen to recall — nothing critical gets skipped.
Q3: What makes a checklist item good rather than bad?
It names a specific, verifiable condition (the what) that two testers would agree on, and leaves the how to judgement. Scripted keystrokes belong in a formal test case, and vague items like “the form works” can’t be objectively ticked — both are poor checklist items.
Q4: Why is a checklist called a living document, and how do you maintain it?
Because the product and risks change. You add any new bug type you find, remove items now covered by automation or no longer relevant, and sharpen anything too vague to tick. Review and prune at least once per release cycle so it stays accurate and useful.
Q5: When would you choose a formal test case over a checklist?
When the test must be re-run identically by different people, when compliance or audit evidence is needed, or when it will be automated — for example a payment-gateway charge that must be traceable to NZ standards. Judgement-based checks by an experienced tester are faster as a checklist.
Try It — Checklist or formal test case?
For each testing scenario below, decide whether a checklist or a formal test case is the more appropriate tool.
| Scenario | Your choice |
|---|---|
| Verifying that a payment gateway integration charges the correct amount to the cent — evidence required for financial audit | |
| Quickly checking that a refreshed marketing landing page looks right across 4 browsers before go-live | |
| Confirming a bug fix for a specific edge case — needs to be re-run by another tester in a different timezone | |
| General accessibility review of a new feature — checking WCAG criteria with judgment calls required | |
| Testing a government portal's identity verification flow that must comply with NZ Digital Service Design Standards |
Answers
| Scenario | Best tool | Why |
|---|---|---|
| Payment gateway audit | Formal test case | Exact steps, precise expected results, traceable audit evidence required. |
| Marketing page cross-browser check | Checklist | Experienced tester knows how to check; judgment-based; no exact steps needed. |
| Bug fix re-run by different tester | Formal test case | Reproducible across testers and time zones requires precise steps. |
| Accessibility review | Checklist | WCAG criteria map naturally to checklist items; requires tester judgment throughout. |
| Government identity verification | Formal test case | Compliance requirement — traceability to NZ standards and audit trail needed. |
The key decision factor: does someone else need to replicate this exactly, or produce audit evidence? If yes, formal test case. If it’s a judgment-based check by an experienced tester, a checklist is faster and just as effective.