Testability Advocacy Canvas

The ‘Testability Advocacy Canvas’ is a tool that I’ve used for a few clients, usually for individuals who want to become testability advocates. Either within a team or wider organisation. There are a couple of different contexts:

• With someone else – used the canvas as an explicit aid to build an advocacy approach for testability with another team member.
• With myself – tracking how my efforts to advocate for testability have evolved, both as an individual contributor on a team or consulting more widely in the organisation.

The various canvases that exist (business model, test automation suite and many more) have this in common, they are excellent at framing your own thoughts and building together with others. Eventually I think you end up with a little of both.

Building the Canvas

There are no rules for ‘filling in’ the canvas, these types of models are best gradually populated. but the sections do flow from topic to bottom:

1. Setting the context with heuristics, skills, value, allies and tactics for testability.
2. Feeding all that into ‘my testability’ (how testable is this context for me) and ‘our testability’ (how testable is this context for everybody).

If testability is to become established, we have to put effort into ‘our testability.’ You can increase testability by testing but that tends to increase ‘my testability’ which dissipates quickly once you are no longer involved.

In terms of section by section guidance:

• Heuristics – anything that you have read that might impact testability or even experiences from your past which seem useful in your current context. Keep an open mind here and capture whatever you think is relevant, a good starting point is the Heuristics of Software Testability by Bach.
• Skills and knowledge – you may have something to share from previous roles or a skill you have been working on as part of your personal development. Prioritise the areas that might help refocus or trigger a change. Creating a run book is a good example, its simple, teams need it and improvements to testability will flow from it.
• Value – from many attempts to advocate for testability in organisations it can be a hard sell. My best advice is to tailor it to the biggest pain points of the organisation, usually a combination of long lead times, live incidents and failed deployments. Use this guide to Benefits of Testability to help.
• Allies – as usual, the longer lasting way of advocating for change is to recruit those who want to help. Knowing their reason for change is crucial here. It might be an operations team who are constantly being woken up by the system but could be very helpful with your load testing efforts if given some breathing space.
• Tactics – one of my frustrations with testability has often been the lack of solid insights into what actions you can take to enhance it. The great thing is that you can pick from many different system quality attributes but that leaves you a little swamped at times. Start with operability, we took a lot of inspiration from it in the testability book.
• My Testability and Our Testability – inspired by this blog post from my recent past. For the canvas, its important to keep the balance. You must increase your testability to be able to advocate for wider testability. Eventually the focus of the advocate switches to our testability much more. The canvas includes space for notes on what can use to help you change your approach (my testability). ‘Our Testability’ includes an area where you look for inspiration within your organisation. SRE and Platform teams are good places to start here.

The downloadable version can be found here:

Give it a try for yourself to guide someone else at your organisation. It would be great to see more ‘Testability Advocates’ out there!