Tag Archives: DeveloperEperience

Poor Testability Is Everywhere — But We Don’t Always See It

Posted on by
4

Rethinking Testability Part 2 – A series of blog posts based on my talk Improving Quality of Work and Life Through Testability

Part 1 – Testability is about people, not just code

Poor testability Slows everything down Adds risk Increase cost Delays Poor quality
Poor 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:

  1. Late discovery of critical bugs — the issue was there, but poor observability or unstable environments kept it hidden until too late.
  2. Intermittent issues that slip through — the right conditions to trigger them are too hard to create on demand.
  3. False confidence — the green checks hides how much effort it took to get there.
  4. Missed learning opportunities — we stop exploring and only do the bare minimum to getthrough.
  5. Burnout — constant friction turns the work into a grind.
Comic strip with a distressed man in front of a computer screen and text saying I once worked at a place where a memory leak took down the website in production. We’d seen symptoms of the issue during testing—but because our environment was flaky, we had a habit of restarting the server. The warning signs were there. But because of distraction from poor testability, the bug stayed hidden until it was too late.

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

The power of pairing

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.

Rethinking Testability Part 3 The Triangle of Perception – why we see testability differently

Rethinking Testability

Posted on by
Reply


Before summer, I had the chance to share my new talk:
Improving Quality of Life Through Testability at GreaTest Quality Convention
It’s a topic that still doesn’t get enough attention — which is why I’m bringing it here, in a 4-part blog series.
Over the years, I’ve collected lessons, stories, and patterns from my own work and from teams I’ve worked with. My goal is to show a different way of thinking about testability — one that’s built for people, not just systems.
When most people hear “testability,” they think about code.
But in my 25 years in software, I’ve learned it’s about much more than that.
Poor testability shows up as slow feedback, missed bugs, fragile automation, and even burnout.
And it’s everywhere — sometimes in ways we don’t notice, because we’ve accepted them as “just how things are.”

Here’s what’s coming up in the series:
1️⃣ Testability Is About People, Not Just Code
→ A more human-centric definition and why it matters.
2️⃣ Poor Testability Is Everywhere — But We Don’t Always See It
→ The recurring patterns and the invisible friction that holds teams back.
3️⃣ The Triangle of Perception
→ Why different roles see the same system’s testability in completely different ways.
4️⃣ Changing the Conversation About Testability
→ How reframing gets people to listen — and the risks that come with it.