#66-Shift left - Detecting Defects During Design

In our continuing effort to shift the detection of defects and other mistakes to earlier and earlier phases in our development process, this week I'll discuss the role that design can play.

Transcript

Shift left: Detecting Defects During Design

Design can be a large-scale development phase, in a waterfall project, or an aspect of each iteration in an agile approach. Either way, when we design the solution that will later be implemented, there are opportunities for us to detect errors, missing information, incorrect assumptions, and failures to understand the true meaning of requirements. 

This is especially true if the design of the product is also test-driven. Most people interpret the acronym "TDD" to mean test driven development, which is true, but the second “D” is also design. We can test-drive a design.

Ideally, as I will discuss next week, the planning phase will have included the creation of acceptance tests by a broad range of stakeholders who will bring detailed knowledge to the table. But the implementation team will almost certainly be proceeding from unit tests if again the entire process is test-driven. 

This means that the acceptance tests, which tend to be more coarse-grained and expressed in human readable language, must be broken down into the fine-grained units that will be expressed in technical language, usually computer code. 

This breakdown process will reveal the entities and behavioral responsibilities that will need to be implemented in the next phase.  If the team has been trained in a variety of breakdown techniques, they should be able to take any acceptance criteria and decompose them into the individual behaviors that need to be developed in implementation. 

If this becomes excessively difficult then one of three things must be true: either the analysis conducted in the previous phase was lacking in precision, or the team does not adequately understand how to break acceptance tests down into behaviors, which is a failure of training, or the previous elements that were determined during the design process were incorrect. 

This last possibility exists because of the simple fact that bad design is difficult to test. If you've ever tried to retrofit tests onto an existing design, you know what I'm talking about. With especially problematic legacy systems, for example, they often have no tests or the tests are very crude. This is because they are not particularly testable. 

Later in this series I will talk about various key qualities in product development that must be adhered to for products to be successful over the long haul, as requirements, business priorities, and market forces change. But what I have determined more recently in my career is that testability is essentially the quality of all qualities. If something cannot be tested with a reasonable amount of effort, or if the tests generated do not themselves stand up to our standards, this is almost always because the design is weak in the sense of the other qualities.  Again, when I lay out what those qualities are, I will relate each one of them to the testability, or lack of testability, of the proposed design.

This is one of the reasons that test-driven development is so powerful, and also the reason that we consider designs to be test-driven as well. It is also the reason that I emphasize in my design and analysis training the importance of considering the testability of requirements, expectations, and design elements as early as possible in the development process. 

Next week we'll see the role this has in the planning phase. See you then!