Testability

Testability is a measure of how easy it is for testing to happen in a given context. Testibility is a measure of many drivers such as people, product, vision, process, time, resources, and problem. These drivers can have a positive effect on our testing, making it easier to test, or they can have a negative effect to making it more difficult to test. Interesting. 

The team's attitudes toward testing can either mean testing is prioritised and supported, or it's an afterthought. A product with many accessible layers such as APIs means we can be more targeted with our testing and automation. Access to testing tools could be restricted due to budget or IT policies. This impacts the types of testing we'll be able to do. 

Knowing about testability informs our testing approaches and our strategies. It provides clear framing for the testing we do and don't do, which helps communicate that work to others, improving testability often delivers more value to the team than doing more testing activities. 

Testability is fluid. Therefore, teams need to periodically review it to ensure approaches are fit for purpose. As testability is an assessment of contact drivers, it can often be biased by those doing the measuring. So it's important to include the whole team.

[When it comes to testability] I've found that any requirement that needs involvement from another team is a hassle to test. You have to align with other teams. That is an extra potential problem. I tend to watch out for those requirements.

The degree to which code is structured in a way that makes it straightforward to write, run, and maintain tests against it. Simon drew a direct connection between testability and clean code principles: when functions have a single responsibility and meaningful names, it becomes much easier to isolate behaviour and write focused tests. Code with poor testability often has tightly coupled components, mixed responsibilities, or hidden dependencies that make it difficult to test a unit in isolation. Improving testability is frequently a side effect of good clean code practices rather than something that needs to be pursued separately.