testability, testing
by Ash Winter

My Ability, Our Ability, Testability

The Three States of Team Testability

Testability is great for making me think. Especially about my beliefs about software development. I love the connected nature of testability to so many aspects of software:

  • If the product is hard to test, then we can test but we will struggle to find important problems. Because we can doesn’t mean we should. We should stop ourselves, step back and ask if it’s hard to test, should we test it? Or least commit to improving it.
  • Testing a thing increases its testability. A hard to test system are more testable by testing them. Whether this takes you in right direction for the team or product is the debate here. Entrenching current behaviours and low testability could happen here. Poor testability persists because we assimilate and accept it.
  • Increasing your ability to test means that systems that are hard to test to others are easier to test for you. In theory, one could become a superb tester and the pain of low testability will leave you untouched. This is not a very inclusive vision. It doesn’t address the core problem of product testability.
  • Increasing the testability of the product allows team testing cultures to grow. This is the foundation upon which team testing cultures flourish. Better product testability creates the space to perform testing. It lowers barriers to all roles contributing. Remember, if it is hard to test, the tester will have to test it.
  • If the product is hard to test, then ability to test is constrained to a high degree. Even if you are an amazing tester with a supportive team, you will bump up against limits. How effective your testing can be with a hard to test product? If you cannot control and observe the product, your testing will suffer.
  • Testable products enable a varied and balanced test strategy. Where you perform many different testing activities to take a broad view of the product. Then make decisions about where depth of testing is appropriate in context. Variety gives motivation to your team to get involved and show their skills. This then leads to even greater testability. This is how great teams test together.

When it comes to testability, I have created some delimiters in my mind. I distinguish between testability (as in something that a product has) and ability to test (something that a person or group has). I know they influence each other. We need to address the balance between polishing our ability to test and designing testable systems. Until these are more equal, we will struggle to build team testing cultures.

I try to keep three states in mind for the teams I am on:

  • My Ability to Test – how well equipped am I to be able to test the product?
  • Our Ability to Test – what capabilities and will does the team have for testing the product?
  • The Testability – how testable is the product itself?

Ask yourself these two questions to get started:

  • Which of the three states are dominant on my team? – if it is my ability to test, you may notice a long list of ready for test items on your board. Try these Testability Questions to get you started.
  • Are the three states aligned on my team? – they need to overlap in to provide the conditions for great testing to happen. Greater testing cannot happen alone. It is constrained by the testability of the product.

Testability is heuristic. The three states and well placed questions can help you to consider where you are as a team. The aim is to make testing better and more accessible to everyone on the team. Every so often, pause to see if you, your team and your system are going in the same direction.