Testability, testing
by Ash Winter

Getting buy-in for testability…

Testability has a major flaw when it comes to real world implementation. It’s mostly thought of as a testers problem. This thinking has persisted for a long time, plus it has some truth. Many other roles are shielded from poor testability and only really see the side effects. Plus we as testers often hide poor testability, either thinking it is our problem to bear or simply adapting to the conditions and doing our best.

Testability is a real team effort however, developers have a massive impact on testability, both of code and system testability. You could argue, they have the biggest impact. There are generally more of them, plus they make loads of decisions about high and low level design which affect your overall testability. I need to finish that blog post too.

But this one is about getting buy-in for improving your testability. Inspired by the crew at DEWT 9, which I could not attend unfortunately. I was really interested in the output though, communicated by my friend Ard Kramer:

Testing and testability have something in common. If you use those words as a pitch for change, you are tapping into long established biases about what testing is, who it is for and what its value proposition is. It probably won’t work. So don’t do it when asking for testability. A little while ago, I created this as a guide, so I thought I would share:

Talk about what people who aren’t testers talk about. We need to deliver, our flow is bad, the system is unstable under load, we struggle to recover from live issues. These map to your testing life too. Questions like why is testing taking so long?, who tested this? and why didn’t we see this before the customers did? map back to these needs.These are also measurable (thank you Accelerate) which helps hugely when it comes to buy in. Better than counting test cases and can actually describe the impact of testing when wielded correctly. Whenever I hear one of the four words (or a mix of them), I pick out a relevant recent example (the blue boxes) and use that as a pitch.

My personal favourite is where there are endless backlog refinement session where we try and split work into deliverable chunks. Then someone suggests “dev” and “test” tickets. Then it’s time to talk about decomposability and safely deploying this work, which helps you to build (smaller chunks giving faster feedback) and safely deploy (faster feedback and risk mitigation). You get some testability, all packaged in desirable outcomes. In this example, less endless backlog meetings. Your team will grow to love you.

There is nothing amazing in here. It’s day to day problems that we encounter, which we can use to improve testability. It’s all part of the same puzzle, so if we advocate for delivery, flow, stability and resilience our testing lives will be so much better.