Releases Don’t Fail Where You Expect
We never have enough time.
Not enough time to run everything.
Not enough time to check every edge case.
Not enough time to feel fully confident.
Yet releases still go out.
So the real question is not:
“Did we test everything?”
It’s:
“What are we choosing not to test and are we okay with that?”
A Release That “Passed” And Still Failed
I’ve seen a release where everything looked fine.
Tests passed
Automation was green
No major issues reported
From the outside, it looked ready.
But after release, alerts stopped showing up correctly.
Nothing crashed. Nothing obvious broke.
But the system stopped telling us what was wrong.
And it took time before anyone noticed.
By then, we were not just dealing with a bug.
We were dealing with a period where the system was effectively blind.
What caused it?
A backend change that didn’t directly touch alerts.
But it affected how data moved through the system.
We tested the change.
We didn’t test what depended on it.
Changes Don’t Break Where You Expect
Most teams think like this:
“We changed X, so test X.”
That’s how things slip through.
Because systems don’t fail in isolation.
They fail in connections.
A database change affects alerts
A policy change affects endpoint behavior
A UI change hides critical signals
The failure rarely sits where the code changed.
It shows up where nobody looked.
What Actually Matters in a Release
I don’t start with test cases.
I start with one question:
If this breaks, does the product still make sense?
That answer is different for every system.
Sometimes it’s visibility.
Sometimes it’s control.
Sometimes it’s the ability to act when something goes wrong.
There is no fixed list.
And that’s where most teams struggle.
Because this requires judgment, not templates.
Most Teams Don’t Lack Time
They lack judgment.
I’ve seen teams run hundreds of tests and still miss critical failures.
Not because they were careless.
Because they were busy proving things work
instead of asking where they might fail.
Automation Can Quietly Mislead You
Automation gives speed.
It also makes it easier to believe things are fine.
I’ve seen:
Green pipelines while critical workflows were broken
Stable suites that never exercised real risk
Passing tests that checked the wrong thing
The problem wasn’t the tool.
It was trusting the signal without questioning it.
The Hard Part Nobody Talks About
At some point in every release, you feel it:
“This part worries me.”
And saying that out loud is not easy.
Because it comes with consequences:
It can delay a release
It can create conflict
It can turn out to be wrong
So instead, teams hide behind passing tests.
It’s safer to say “everything passed”
than to say “something feels off.”
A Simple Rule I Follow
Test the system, not just the change.
Because releases don’t fail in the code you touched.
They fail in the parts you assumed were safe.
Final Thought
A release is not a testing problem.
It’s a decision under uncertainty.
And every test you run, or don’t run, is part of that decision.
The question is:
Are you choosing intentionally, or just executing what’s in front of you?
Further Reading
If you found this useful, you might also enjoy these articles:
If you found this helpful, stay connected with Life of QA for more real-world testing experiences, tips, and lessons from the journey!