Testability can make our testing lives so much better. But we need to sell it to those who can pay for the changes needed. Find out what they need (delivery, flow, stability, resilience), how it can be measured the use the handy examples below!

1. Benefits of a Testability Focus
Perceived Need – Delivery, Flow
Lead Time – code
commit to deploy to
Production
Deployment Frequency –
more frequent
deployments with smaller
batch size
Perceived Need – Stability, Resilience
Mean Time to Recovery
– time to recover from a
Production failure
Change Fail % –
deployments requiring
roll back or fix
Easier to test means
finding important
problems earlier, rather
than just before
important decision
points.
A testable system is
more decomposable,
easier to break down
into smaller stories. No
more long backlog
sessions on how to split
stories.
If the system is more
testable, more team
members will be able
and want to test it. No
more "testing
bottleneck” holding the
whole team back.
Greater observability
helps us to see
problems before they
manifest. Observe
system changes and
investigate, rather than
only seeing causes.
More roles within the
team are willing to be
support the system. Not
only developers who
end up on call, which
promotes team
harmony.
Reduction or removal of
release testing phases
as early testing is much
more effective. Much
less repetition of
testing.
Better relationships with
the teams and
interfaces that you
depend on. If your
dependencies are hard
to test, it constrains
your testing.
Reduce dependence on
individuals who hold key
knowledge. Testability
encourages sharing,
documentation and
transparent team
decision making.
Refactoring becomes
standard, as you have a
balanced test strategy
to cover you. Fewer
performance-based
surprises especially.
Diagnose and triage the
lists of defects that have
built up over time. Less
sorting and ranking in
backlog grooming. Quick
to prove problems still
exist.
Remove test
environments that don’t
enable the testing you
need. Get your pipeline
to mirror your test
strategy.
Think about how to test
and support your
architecture early and
often. Testing and ops
are closely aligned, they
value uptime and
resilience.
Translate incidents into
actionable information
on how and what you
test. Test where it
matters most by
refreshing stale test
strategies.
Testable systems mean
more of the most
effective testing but can
mean less spend on
testing overall.
Reduce the areas of the
system where teams
fear to make changes.
You can make changes
when you want and
need to.
Information from testing
helps with present and
future product
decisions. Build more of
the right thing based on
reality not claims and
assumptions.
Cleaner interfaces and
versioning help with
customer integration.
Testability encourages
clean interfaces
between systems
requiring less support.
Testability leads to a
balanced test strategy.
More focus on security
and performance testing
as the system becomes
more observable and
controllable.