Checklist-Based Testing
Speed meets structure. Learn how to use high-level lists to ensure you never miss a basic requirement — without getting bogged down in 50-step test cases.
1 The Hook — Forgetting the Basics
A tester at a NZ grocery delivery app once spent three hours testing a complex new "Loyalty Point" feature. They verified the math, the database, and the API. It was perfect.
But when they went to production, they realised they'd forgotten to check if the "Pay" button worked on an iPhone SE. It was hidden behind the keyboard. They'd tested the "Hard" stuff and forgotten the "Basics." Checklist-Based Testing is the safety net that ensures the basics are always covered while you focus on the complexity.
2 The Rule — High-Level Conditions
Use structured lists of "What to verify" rather than "How to do it."
A good checklist item isn't a step; it's a Quality Goal. For example:
- Test Case Style: "Click field, type '1010', verify no error." (Slow)
- Checklist Style: "Verify postcode field only accepts 4 digits." (Fast)
3 The Analogy — The Airline Pilot
The Pre-Flight Checklist.
Even a pilot with 20,000 hours of experience uses a checklist. They know how to fly the plane, but they use the list to ensure they don't forget something small — like locking the fuel cap — that could cause a disaster. Testing is the same. You know how to test a login, but the checklist ensures you don't forget "Remember Me" or "Forgot Password."
4 Watch Me Do It — The SANITY Checklist
Scenario: You're testing an e-commerce checkout for a NZ clothing brand. Use the **SANITY** mnemonic checklist.
| Letter | Meaning | Example for NZ Checkout |
|---|---|---|
| S | Success Path | Can a user buy a shirt and see the "Thank You" page? |
| A | Alerts & Errors | Does it show a red error if the credit card is expired? |
| N | Navigation | Can I go back from the payment page to change my size? |
| I | Inputs | Do NZ Postcodes (4 digits) work correctly? |
| T | Totals & Tax | Is GST (15%) added correctly to the final price? |
| Y | Yield (Performance) | Does the page load in under 3 seconds on mobile? |
5 Decision Tool — Checklist vs. Test Case
✅ Use a Checklist when...
- The feature is simple or standard.
- The tester is experienced and knows the app.
- You need to test quickly (Regression).
🛡 Use a Test Case when...
- The math is critical (Payroll, Banking).
- A Junior tester needs step-by-step help.
- You need "Proof" for an external audit.
6 Common Mistakes
🚫 Making the list too long
I used to think: I should add 100 items to the checklist to be safe.
Actually: If a checklist is too long, people stop reading it. Keep it to the "Top 10" critical things. If it's more than a page, it's a manual, not a checklist.
🚫 Never updating the list
I used to think: Once the checklist is done, it's done forever.
Actually: Checklists must evolve. If a specific bug keeps appearing in production, add it to your checklist so it never happens again.
7 Now You Try — Formal vs. Flexible
Scenario: Decide which tool is better for these scenarios.
A quick check that the logo looks right on 5 browsers.
Checklist (Judgment based)
Verifying that the IRD tax calculation is correct to the cent.
Test Case (Precision required)
Testing a brand new government identity portal with an auditor.
Test Case (Audit trail needed)
Confirming the "Contact Us" form works after a server move.
Checklist (Simple validation)
8 Self-Check
Q1. Are checklists "Black Box" or "White Box"?
They are Black Box (or Experience-based). They focus on the behavior of the software, not the code inside.
Q2. Where do we get the items for our checklists?
From requirements, industry standards (like WCAG), and historical defect data (what broke last time?).
9 Interview Prep
"How do you balance thoroughness with speed in a fast-moving sprint?"
Answer: "I use a tiered approach. I use formal test cases for high-risk, complex features, but I rely on standardized checklists for regression and common UI elements. This ensures the 'Basics' are always covered efficiently, allowing me to spend more time on deep exploratory testing of the new features."
10 Next Step
You've mastered testing from the outside. Now, it's time to look Inside the Code. Next: Statement Coverage.