Rethinking Testability Part 4 (Last post) – A series of blog posts based on my talk Improving Quality of Work and Life Through Testability

Rethinking Testability Part 1 – Testability is about people, not just code,  Part 2 – Poor Testability is Everywhere – but we don’t always see it Part 3 – The triangle of Perception

Reframing Testability

Over the years I’ve learned that: Starting a conversation by talking about testability, I can lose people pretty fast.

Not because they don’t care about it — but my guess is that testability just sounds too niche, too tester-centric. And to some it might just seem too technical and maybe a bit too dry for people to immediately feel connected with.

So I started framing it differently.

Leading With Developer Experience

Instead of testability, I’d talk about Developer Experience — or sometimes Developer Productivity, depending on who was in the room.

I genuinely care about Developer Experience — and it overlaps heavily with testability. And it seemed like that concept is easier for people to connect with.

Most developers know the pain of:

• Waiting forever for a build to finish.
• Having to restart flaky environments multiple times a day.
• Wrestling with tools that block instead of help.
• Getting interrupted mid-flow by issues that shouldn’t be issues.

Those things drain energy, slow learning, and make people feel less effective.
When I talk about them as Developer Experience problems, people nod immediately.

But here’s the thing: those are also testability problems. Because every one of those frictions makes it harder to observe, control, and explore the system.

Where Productivity Comes In

On the other side, Developer Productivity is a term that seemed to often land better with leaders or managers, because it speaks directly to business outcomes: speed, efficiency, predictability.

If you say “poor testability slows us down,” you’re talking productivity.
If you say “better testability means faster learning and fewer surprises,” you’re also talking productivity — just in a way that connects risk and speed.

The overlap is there. Testability affects both how productive teams feel (experience) and how productive they are (output).

But here’s the risk: if I only frame it in terms of speed, I risk losing the deeper point. Testability isn’t about going faster —it’s about efficiency, how easily we can explore a system, uncover risks, and challenge the product itself.

The Catch-22 of Testability

One of my biggest challenges is that: improving testability often feels like a Catch-22.

• To show the value of improving it, you first need better conditions.
• But to get those better conditions, you often need to show the value up front.

I’ve seen this happen with tools, environments, and processes. Everyone would benefit if they were more stable or better supported. But getting buy-in often comes down to one question – related to productivity:

“How much time will this save?”

It’s a fair question. But the real value isn’t only about saving time.
It’s about reducing blind spots.
It’s about enabling exploration earlier.
It’s about noticing problems sooner — and avoiding the burnout of constantly fighting the system.

Those benefits are harder to measure, but they’re the ones that really matter.

The Bigger Picture

This is the thread running through the whole Rethinking Testability series:

• Testability isn’t just about code.
• Poor testability shows up everywhere, often in invisible ways.
• People perceive it differently depending on how they interact with the system.
• And the way we frame it shapes whether others understand its value.

At the heart of all of this is one simple idea: testability shapes quality of life.
Not just the quality of the product — but the quality of life for the people building it.

Improving and Advocating for Testability

Improving testability isn’t the responsibility of one person or one team — it’s something we can all influence:

As a tester
Don’t just share results — share the story behind them. If it was painful to get there, that friction is a signal. Speaking up about it reveals risks others can’t see.

As a developer
Think beyond “code that works.” Ask yourself: can someone easily observe, control, and explore this system? Design for exploration, not just validation.

As a leader or product owner
Seek real confidence, not just green dashboards. Ask: where are teams fighting the system instead of learning from it? Your support can make the difference between friction and flow.

The Takeaway

Testability isn’t really about speed. It’s about making our work smoother, our learning faster, and our confidence real. And when we improve it, we’re not just improving our products — we’re improving the experience of everyone building them.

That’s why I believe testability deserves more attention.
Because quality of life at work isn’t separate from quality of the product. They rise and fall together.

Rethinking Testability Part 1 – Testability is about people, not just code,  Part 2 – Poor Testability is Everywhere – but we don’t always see it, Part 3 The Triangle of Perception: Why we see testability differently