Engineering for testability intends to create a culture of co-development for all who contribute to a product, working to reduce toil and tension caused by difficult to test systems.
We understand that risk will accumulate in every layer of a system if they do not have feedback loops. If your system does not provide application and diagnostic information for each architectural layer, the value of your tests will be compromised.
We will work towards a highly testable system which is the most effective route to enabling whole team testing cultures. Easier to test systems encourage empathy, skill transfer and shared responsibility of testing by removing the perception of testing as a bottleneck.
We believe that the testability of our application architecture is a leading indicator of quality. Designing our architectures for testability, with early and often consideration for testing increases flow of value and reduces toil.
We believe that the quality of our relationships within our organisation increase testability by profound understanding of risk and reward. Knowing what is valued by the team and those connected to it targets our testability to the best return on investment.
We understand that a testable system enables deep investigation of the risks that we identify and unanticipated problems that may occur. Testing is skilled exploration for information about threats to value, instrumenting our application code to increase observability enhances that exploration. Observability tools and techniques are the lens to visualise and filter that information.
We understand that when your system state is not controllable the side effects of testing cannot be observed, which compromise the effectiveness of your testing. For testing to give the most relevant and timely information, controllability is required.
We believe that a highly testable system is more operable for our contributors and customers, reducing their toil and frustration. The practices of operability lead to testability gains, removing many of the obstacles to effective testing.
We will work to understand and improve the testability of our dependencies, so as to increase our own testability. We recognise that if one of our dependencies has poor testability, own own testability will be constrained.