Poor Testability Is Everywhere — But We Don’t Always See It
Rethinking Testability Part 2 – A series of blog posts based on my talk Improving Quality of Work and Life Through Testability
Symptoms of Poor Testability
I’ve worked with a lot of different teams and organizations over the years, and I’ve seen the same problems repeat themselves in places you’d think had nothing in common.
Sometimes the symptoms are obvious but very often not understood as testability problems.
– A test environment that is not available.
– Logs which are unavailable or hard to read.
– A new team who is not yet familiar with the product.
The Patterns I Keep Seeing
When testability is poor, I usually see some mix of these five problems:
- Late discovery of critical bugs — the issue was there, but poor observability or unstable environments kept it hidden until too late.
- Intermittent issues that slip through — the right conditions to trigger them are too hard to create on demand.
- False confidence — the green checks hides how much effort it took to get there.
- Missed learning opportunities — we stop exploring and only do the bare minimum to getthrough.
- Burnout — constant friction turns the work into a grind.
The first four mainly hurt the product – at least at first.
The last one hurts people.
The Burnout Nobody Talks About
One of the hardest moments I’ve witnessed came from the fifth problem.
A tester I worked with broke down in tears. Not because of bad feedback from a manager, or a bug escaping to production — but because every single day was a fight just to do the basics.
He couldn’t get the system into the right state.
He couldn’t trust the tools.
He felt blocked at every turn.
That’s not “just part of the job.” That’s the personal cost of low testability – and a loss for the organization where this person works.
The Invisible Friction
Sometimes poor testability hides in plain sight — we’ve just gotten used to it.
On one project, a tester had to go through the entire customer journey before they could even start the actual test:
Simulate a purchase — > Step through the install flow — > Confirm the configuration
Every day. Several times a day.
Nobody questioned it. It was just the way things worked.
Until one day, a developer sat down, watched the whole process unfold, and said:
“Wait… you do this every time? I have a script that does all of that.”
That moment said it all.
Sometimes the biggest testability problems aren’t hidden in the system — they’re hidden in our habits.
How to Spot It
If your team is struggling with testability — whether you realize it or not — there are a few ways to surface the pain:
- Pair up — have someone from another role watch you set up and run a test. Fresh eyes see friction you’ve stopped noticing.
- Map the setup — document the steps just to get into a testable state. Investigate which of those could be simplified or perhaps automated/scripted
- Ask “how” and “why” more often — tell the story of how it was tested and why, the story about the testing itself may reveal interesting information about testability.
- Run a testability workshop with your team — these are workshops that I often run with teams and it starts with a simple question: “What is making it hard for you to test?”
The Real Point
Poor testability isn’t always loud.
Sometimes it creeps in slowly, hidden behind workarounds and “just the way we do things.”
But whether it’s obvious or invisible, it is costing us.
It costs us time, it costs us learning, and — over the long run — it costs us the energy and motivation we need to do our best work.