I recently attended a talk by Ralph Johnson which I enjoyed.

One theme that Ralph talked about was simplicity. He was talking about security patterns, and how simplicity of design implies knowledge. If a design is knowable, it can be made secure. That led to a thought for me on testability. This is also true of a testable design; if a design is simple, it is knowable and therefore testable.

For example, as a tester one is often asked to look at requirements or user stories to determine if they are testable. If you as a tester can understand them, that’s a good indication that they are testable. If you can’t, how can you (or others) test? In my experience, when no one person understands or knows the project, it is difficult to test. If I need to go around to seven different people to understand the design of a project and none of them understand it in its entirety, chances are the project will be equally as difficult to test. Legacy systems suffer from this, but poorly designed new software projects are also difficult to test.

As a tester, if you don’t understand the design, don’t automatically think that you lack the necessary technical skills to understand. The architectural designs should be understandable to any stakeholder involved with the project (once the convention is explained to them). If the design isn’t understandable at a high level by the entire team, this is probably a bad design smell.

Ralph also mentioned that tools such as UML or DFDs serve to express program design to other people. (The opposing view is that these tools are used to generate code.) I agree with Ralph that these tools express design to be communicated to other people. If the architectural diagrams are easily understood, they will not only be testable, but more easily developed and communicated to the business. Tool generated code is extremely difficult to know and to test. People design software, people develop software, people test software, and people use software. The tools are there to help express each of those roles.