This content was originally posted here in collaboration with my good friends at PractiTest. It is reproduced here so there is a complete article record somewhere.
Your system is hard to test. It’s hard to control state. Hard to see the information it emits. Components have side effects you can’t isolate. Even information sharing between contributors is limited.
Whenever I consult with a new organisation, I have three working assumptions. That they have too much work in progress. They don’t spend enough time paying back technical debt. And that their systems are really, really hard to test. Prove me wrong.
I was working at a large media company that had these problems. Their system was complex, many problematic dependencies, end of life plus ten years systems. Many programming languages, hard to deploy, blind sided by production issues. You get the picture.
At the sharp end of testability problem, many people asked the testers. “Why is testing taking so long?” “When will testing be done?” When it was my turn, once I’d dealt with the initial query, I gave the same message. “We, as a group of software development teams, have not taken collective responsibility for testability.”
I’m going to cover the following in this article. These should help your team to focus on testability and help your stakeholders to understand why:
- Testability helps you deliver what your stakeholders value most, at a known level of quality. It’s a competitive advantage.
- We need all roles involved in testability. So we need to make a case to other disciplines including developers, operations and design.
- Although testers are not the sole custodians of testability, we have to start from where we are. We are the ones who need to get started.
Testability is a competitive advantage
Let’s get down to business. Organisations probably have many ‘quality improvement’ initiatives in progress at any one time. Why is testability more important than any of the others? I believe that testability gives you a competitive advantage.
The delay between programming a thing, testing a thing and deploying a thing is where so much of the cost of software development lies. Dwell time. Value waits in queues to be realised. When effort is often the measure, the real cost lies in dwell time.
Testability helps in two ways:
- Better testability means better team cohesion. If teams can move as one, dwell time is reduced, especially when building small but valuable items. Testability helps teams move as one by reducing the time taken to start testing. I often find testers waiting for something, then rushing to finish. Usually followed by a description of testing as a bottleneck. This shows both a lack of team cohesion which can be traced back to poor testability.
- Better testability means less technical debt. If you have a test strategy that is well understood. And tests you trust when you make changes to testable system you will be able to deliver safely with speed. For example, so many teams struggle to update their software dependencies, core libraries as they don’t know what the impact might be. It doesn’t have to be this way.
Getting your team on board
Wherever I talk or write about testability, the main query I get regards how to “sell” testability to the team or wider organisation. The answer to this is always “it depends.” Depends on the type of person who you are dealing with. Most of us need to see testability in our own context before we buy in. Some people might not want to talk about testability at all.
If you are a person who is happy to facilitate a discussion, then try one of these two options:
Guiding your team through the The Team Test for Testability
https://github.com/ConfluxDigital/testability-questions
The benefit here is that it doesn’t mention testability as a concept. Less likely to trigger any of the biases that exist. The ones which say that testers are wholly and forever responsible for testability.
Collaborating on a team run book
https://github.com/SkeltonThatcher/run-book-template
Here’s a little secret. The more operable your system is, the more testable it is. Its deployable (test the build you want), better understood (modelled traffic, business stakeholders engaged), more resilient (test when you need to) and so many more.
Get some coffee and your team’s favourite snacks. Book a room and get your team involved with collaborating over each area of the run book template. Don’t worry about filling in every box, the key is the conversation. Everybody wins when you have better operability. Why not testers as well?
If you might are less sociable than facilitating a discussion and prefer one on one situations. Then you need to find yourselves an advocate to help. Most testers have a person or two on the team they collaborate with more than others. Get them on board first. Some strategies include:
- Developers: They want fast feedback and then to move on to the next challenge. I often sell testability with less context switching. Rather than testing happening a few days after they have been deep in the programming process. Talk about a world where tests of all levels can be run locally, rather than waiting for builds to complete. Where you can exploratory test on their code while it’s still on a branch. Moving at the same cadence.
- Operations: Your Database Admins and Application Support are often long suffering. They are excellent allies to get behind a focus on testability. Better resilience, logging, monitoring, configuration and security mean less toil for them.
- Design and Analysis: I often find designers, user experience practitioners and analysts as allies for testability. They often don’t have the ability to change the system itself to render it more testable but testability is more than that. It is about relationships with customers too. Testing ideas and assumptions about what they need. Building less, but the right thing is the aim. As testers we should be aiming for the same, testing less, but testing what matters.
Testers need to start the ignition
Collaboration is the aim, but you can only start from where you are. Where we are is usually that testers are responsible for testability. We need to move the needle away from this towards everyone taking responsibility for testability. To get you started, here are three quick ways to get the ignition started:
- Show that advocate you found how and what you test. You may need to be vulnerable here. When we have tested a system for a long time, we have subconsciously learned to work around the hard to test parts. The advocate may be surprised at how and what you test. Showing the pain often leads to simple changes that make your testing life much better.
- Talk about what matters to your audience. I talk about operability, it makes sense to me. After all, if you can’t deploy safely, what use brilliant testing? In your organisation it might be something else. If you test in a distributed microservice architecture you might focus on observability. Find the key, try a few different angles.
- For the last ten years I have tested on a local development environment. Same as the developers, one team. moving together. I can’t recommend this highly enough. There is still a case for persistent environments but try to lessen your reliance on them. This helps those who maintain them too. Every complaint about test environments usually just adds to someone else’s work load. It doesn’t help.
There are three key takeaways here:
- Testability is a competitive advantage. By bringing teams together and focusing on technical excellence, testability helps to reduce the amount of dwell time we accumulate.
- We need to find a way to communicate the value of testability. Fortunately testability gains can be made from other capabilities, such as operability. We can move the testability needle with group exercises or even one on one interactions.
- We can only start from where we are. We as testers will often need to be the ones who start the ignition and make changes to what we do to encourage a testability focus.
The quality of your testing is limited by testability. Whether this is your technical understanding of the system, your relationships within the team or how observable the system itself is. I believe the future of testing depends on how we advocate for and implement testable systems. It is time for everyone to take responsibility for testability. When I say everyone is responsible for something, it always has to start from the same place. You.
Diagram Industries 