As part of the Team Guide to Software Testability, Rob Meaney and I have focused a great deal on testable architecture. We believe that architecture is a key enabling constraint to testability. As long as the teams that build and operate the system can evolve it of course.
As far as guidance goes:
- Needs – In the centre, we see various needs for testable architecture, usually manifested in the things actors say “how confident are we” and “this seems complex.”
- Threats – The next layer is threats to those needs. Unknown change side effects, system myopia, claims about performance, dependencies and team confusion over boundaries and responsibilities are examples here.
- CODS – The CODS model provides a framework to consider actions based on the needs and threats. Controllability, observability, decomposability and simplicity are traits that are desirable for our system. There is no one to one link between a trait and an action, you will likely get a combined impact.
- Operability – This is all wrapped in the principles of operability. Operability provides an excellent frame for testability, plus another language for it for those hard to reach stakeholders. Ops and testers have a lot in common (think cost centres, outsourcing, skill devaluation), we should build that relationship.
- Experiments – From the right comes a number of experiments on improving the testability of the architecture. New tools and techniques that the team can experiment with. The narrowing of that section is purposeful. Testability is a systems thinking endeavour, change multiple variables and it’s hard to determine a positive difference.
- Lessons – As experiments enter the architecture, so must other established aspects be candidates to leave it. Striving for simplicity means removing either components, simplifying them or even practices that provide little value.
More generally, beware target architectures too. Growth, customer usage and product roadmaps make your architecture a moving target too. Evolve based on experiments, basically something you can test.
Retrofitting testability is very hard, equally so waiting for a rewrite or re-platforming enable greater testability. Use the CODS model, wrapped in the principles of operability and run testability experiments with your team. Start from the place that makes the most sense. Where you are right now.
Diagram Industries 