Design for Testability
To accelerate the achievement of shippable quality, solutions should be architected and designed for increased testability.
Testability is the characteristic of being easy or amenable to testing and checking. Solutions that are designed with testability concerns in mind, facilitate faster feedback and faster delivery.
Teams should ensure they ask themselves "how are we going to test this?" Delivery Teams and those architecting solutions should consider the different facets of testability, including:
- controllability: the degree to which it is possible easily to control the state of a software component and place it in a state needed for a test or check
- observability: the degree to which it is possible to observe the internal state of a component or system from external features or to obtain the outputs of a process
- isolateability: the degree to which the component can be executed in isolation in order to observe its behaviour (during checking and testing)
- separation of concerns: the degree to which the component has a single, well defined responsibility
- understandability: the degree to which the component under test is documented or self-explaining
- automatability: the degree to which it is possible to automate testing of the component under test
- heterogeneity: the degree to which the use of diverse technologies requires to use diverse test methods and tools in parallel
- Testability blog post by Michael Bolton (https://www.developsense.com/blog/2009/07/testability/)
- The Team Guide to Software Testability by Ash Winter and Rob Meaney (https://leanpub.com/softwaretestability)
- an example of controllability might be the ability to put an ecommerce into a state immedately before checkout without having to manually perform customer actions
- an example of observability might be controllable levels of logging, accessible by product engineers in any environment in real time.