Testable software architecture in a nutshell

Many software architects concentrate so much on the customer’s  requirements/needs, that they overlook other key sources of requirements from the professionals that work on creating and delivering the project like developers, testers, designers, deployment/production staff etc. Forgetting to map their extra requirements can result in substantial project delays, poor quality, cost overruns and failed projects altogether.

In this posting I will concentrate on testing issues and provide a bit of practical advice on what a good architect should always keep in mind regarding testability. Thus enabling high quality of the solution and making sure professional testers and developers alike can be effective.

Most importantly, the architecture, design (and requirements) of the system should be made explicitly testable. As an architect you start out with the basics of good design like separation of concerns & being able to code/run/test/debug objects in isolation. Then you make sure you have also designed for:

• controllability: The degree to which it is possible to control the state of the component(s) under test before/after a test is run. Most importantly, a tester or automated sw test must be able to roll back changes in state, so that the test can be repeated (regression testing). This may involve designing a system providing additional transactions for tests, rollback scripts, new Api methods or gui controls to modify the system just for test purposes.
• observability: The degree to which it is possible to observe (intermediate and final) test results.  Most importantly, a tester or automated sw test must be able to inspect all relevant data/values/attributes in the system to evaluate if the test succeeded or not . This may involve designing a system with extra Api methods or gui controls just for being able to read or display state.
• automatability: The degree to which it is possible to automate testing of the component under test. Making sure a system is both controllable and observable usually goes a long way in enabling automate testing. But sometimes features in f.x. security/authentication  block the ability to automate testing. In these cases a separate “unsecure” mode may be needed for automated testing.

Note that designing for testability may seemingly contradicts user requirements – f.x. if the user specifies that one must never be able to delete a data item in the system and the controllability requirement insists that you make sure that all data items can be deleted. Here it is important that there is in fact no such conflict as the user requirements deals with the finished delivered system in production while the testability requirements are concerned with your development and test environments.