Table Of Contents
There’s a version of QA that exists in a lot of organisations. It’s not talked about openly, but everyone knows it’s there.
It goes something like this: testing happens because it has to. There’s a box on the release checklist. Someone needs to sign off. The process requires evidence that “testing was done.” So testing gets done, just enough to satisfy the requirement, and the release moves forward.
I call this checkbox testing. And while I understand why it exists, I’ve seen it fail too many times to pretend it works.
This is Part 1 of a two-parter. Here, I’ll talk about why checkbox testing happens, what it catches, and what it misses. In Part 2, I’ll cover what taking testing seriously actually looks like, and why it doesn’t have to cost more.
Why Checkbox Testing Exists
Let’s be honest: checkbox testing doesn’t come from nowhere. It’s usually a rational response to real constraints.
Compliance pressure. Some industries require evidence of testing for clients, audits, certifications, or regulatory approval. The focus becomes “can we prove we tested?” rather than “did testing find anything useful?” The paperwork matters more than the outcome.
Time pressure. Deadlines are tight. Features are late. QA gets squeezed into whatever time is left. There’s no room for thorough testing, so the team does what they can and hopes for the best.
Cost pressure. Testing is often seen as overhead, not investment. When budgets are tight, QA is an easy target. Fewer testers, less time, lower expectations. The goal becomes “test enough to ship,” not “test enough to be confident.”
Lack of QA maturity. Some organisations have never had strong QA practices. They don’t know what good looks like, so they default to the minimum. Testing is something that happens at the end, performed by whoever is available, with no real strategy behind it.
None of these are excuses. But they are explanations. Checkbox testing isn’t usually malicious. It’s often just the path of least resistance when quality isn’t prioritised.
The Illusion: “We Tested It” ≠ “It Works”
Here’s the dangerous part.
Checkbox testing creates an illusion of quality. The release notes say “tested.” The sign-off is complete. Everyone assumes the software works.
But “we tested it” and “it works” are not the same thing.
You can test software and miss critical defects especially if you only test the “happy path”. You can execute a hundred test cases and still not cover the workflows your users actually care about. You can tick every box on the checklist and ship something that breaks in production.
The checkbox doesn’t know the difference. It just knows it got ticked.
This is where organisations get burned. They think they’ve managed risk because testing happened. But they haven’t managed risk at all. They’ve just created documentation that says they did, but what was covered and what tests were executed is ignored.
What Checkbox Testing Catches
To be fair, checkbox testing isn’t completely useless. It catches some things.
Obvious defects. If something is completely broken, even shallow testing will find it. Buttons that don’t work, pages that don’t load, errors that appear immediately. The low-hanging fruit.
Regression in stable areas. If you’re running the same tests every release, you’ll catch regressions in the areas you’re covering. As long as those areas don’t change much, and the tests are still relevant, you’ll get some value.
Compliance evidence. If the goal is to prove testing happened, checkbox testing achieves that. You’ll have test cases, results, and sign-offs. Whether they reflect real quality is a different question, but the paperwork will be there.
For some organisations, this is enough. They’re not building safety-critical systems. The cost of defects is low. They can afford to fix things in production. Checkbox testing is a calculated trade-off.
But for most organisations I’ve worked with, it’s not enough. And the problems show up eventually.
What Checkbox Testing Misses
The real cost of checkbox testing isn’t what it catches. It’s what it misses.
Edge cases and integration points. Checkbox testing tends to follow the happy path. It doesn’t probe the boundaries, the unexpected inputs, the places where systems interact in complicated ways. Those are often where the worst defects hide.
User experience issues. A test case can verify that a workflow completes. It can’t tell you that the workflow is confusing, slow, or frustrating. Checkbox testing doesn’t ask “is this good?” It asks “does this technically work?”
Context-specific risks. Every product has areas that matter more than others. Features your biggest customer depends on. Workflows that spike during certain periods. Integrations that are fragile. Checkbox testing treats everything equally, which means it under-tests what matters most.
Emerging patterns. When testing is just a checklist, there’s no one looking at the bigger picture. No one asking “why do we keep finding defects in this area?” or “what does this trend tell us?” The focus is on getting through the list, not learning from it.
The things you didn’t think to test. Checkbox testing is, by definition, limited to the checkboxes. If something isn’t on the list, it doesn’t get tested. There’s no room for exploration, intuition, or following a thread that doesn’t fit the script.e form, by injected humour, or randomised words which don’t look even slightly believable.
The Real Risk
So what happens when checkbox testing misses things?
Escaped defects. Issues make it to production. Users find them. Support tickets pile up. Reputation takes a hit. Depending on the defect, the impact can range from minor embarrassment to major financial loss.
Technical debt. Quick fixes get layered on top of undetected problems. The codebase becomes harder to maintain. Future changes become riskier because no one fully understands what’s underneath.
Eroded trust. Stakeholders lose confidence in QA. “We tested it” stops meaning anything. The team that’s supposed to provide assurance becomes the team that “missed it again.” That’s a hard reputation to rebuild.
Reactive firefighting. Instead of preventing problems, the team spends its time responding to them. Production issues, hotfixes, post-mortems. It’s exhausting, demoralising, and ultimately more expensive than doing it right the first time.
I’ve seen all of these play out. Sometimes in small ways, sometimes in ways that cost real money and real trust. The pattern is always the same: testing was treated as a box to tick, and eventually the box wasn’t enough.
The Hard Truth
Here’s what I’ve come to believe after 20+ years in this industry.
Checkbox testing is a symptom, not a root cause. It happens when organisations don’t value quality enough to invest in it properly. When QA is seen as a cost to minimise rather than a capability to build.
You can’t fix checkbox testing by adding more checkboxes. You fix it by changing the mindset. By treating testing as a discipline, not a formality. By asking “what could go wrong?” instead of “what do we have to test?”
That’s not always easy. It requires buy-in from leadership, particularly from those that think “we’ve been doing OK”. It requires time and resources and it needs to scale. It requires people who know how to test well, not just people who can follow a script.
But it’s possible. And it doesn’t have to cost more in the long run. Done right, good testing saves money by catching problems early, reducing rework, and building confidence in releases. This feeds into the entire release pipeline, not just the Jira ticket we sign off on during the sprint.
What’s Next
In Part 2, I’ll talk about what “taking testing seriously” actually looks like in practice. Not theory, not idealism, but practical approaches that work in real organisations with real constraints.
The goal isn’t to test everything. It’s to test what matters, with intention and focus. And to build the kind of trust where “we tested it” actually means something.
That’s where the real value lives.
A Note on Context
Every business and every project is different. What works in one place won’t work in another, and that’s the point.
Nothing here is meant to be a step-by-step prescription. It’s guidance, drawn from my own experiences, and deliberately kept general to avoid pointing fingers anywhere.
Take what’s useful, ignore what isn’t, and adapt it to your own context. Or as Joe Colantonio always says: “Test everything and keep the good.”
