Agile Tips
Unlocking Agile Wisdom: Insights from Decades of Experience. Scott Bain is a 44+ year veteran of systems development.
Agile Tips
#65-Shift left - Detecting Defects During Implementation
This week we will examine how defects can be detected and sometimes even prevented during the implementation of the product as analyzed and designed in the previous phases.
Shift left: Detecting Defects During Implementation
If you have been following this podcast and my other work, you probably assume that I'm going to say that detecting defects during implementation is a benefit when the team embraces test-driven development.
This is, of course, true! When tests are written as part of the creation of the system, then the system is fundamentally tested by the time implementation is complete. This reduces the burden on the phases that follow in that there are fewer defects for them to detect in the first place.
If you are unfamiliar with the notion of test-driven development, see the transcript for a link to a webinar that I did on the topic which has been recorded, and which can be viewed at any time.
But in addition to this, some of the decisions made in the implementation phase can make some defects impossible. To understand this, we have to examine the difference between defect prevention and defect detection.
Imagine a component that allows you to record an individual as a member of a baseball team. Among the other information that would be supplied to such a component would be the position that that person is being assigned to play. Even if you are not that familiar with the game, you probably understand that the positions would include pitcher, catcher, first baseman, left fielder and so forth.
The implementation team would have to make a decision as to how to record the position being assigned. If they decided to assign each position a number, pitcher being 1, catcher being 2, and so forth and given that there are 9 positions on a baseball team, then a decision would have to be made as to what the system should do if an attempt is made to record a player whose position is indicated as less than 1 or greater than 9.
There are a lot of options as to what the system might do under those circumstances. It might refuse to take the player assignment. It might decide to take any number greater than 9 and reduce it to 9 and increase any number less than 1 to 1. They might decide to do modulus arithmetic meaning that the number would be converted to base 9 such that 10 becomes 1 and so forth. You might think of other things that the team could do, but whatever it, is would be a behavior that would require a test to drive it. That test would have to be written, observed to fail, and then made to pass through the actions of the team. It would also be retained for the future, put into version control, run on a regular basis to make sure that the behavior had not become defective, and so forth.
Depending on the technology being used, that may be the only way to create the proper systemic behavior.
On the other hand some development environments allow for the creation of specific named entities. Developers refer to these as “enumerations” and are often used to capture something like the day of the week, or the month of the year, or anything that can be defined as a finite set of elements. The positions on a baseball team could be modeled in this way, and if they were, then any attempt to pass to the component something that is not a legitimate member of that set would make the system fail to compile.
This would be a prevented defect not in the sense that it would prevent other developers using this component from making such a mistake, but rather that the mistake could never make it into the product that moves into the next phase of development.
This also answers a question that I am often asked, which is: how should the development team determine that they have done sufficient testing? They don't want to test excessively, but they also don't want to hand off buggy code to the integration effort.
My answer to them is always: any defect that can be prevented should be, and no test should be written because that test could never fail. A test that cannot fail is waste. But many if not most defects cannot be prevented and so any of those potential issues must have tests, otherwise the test suite is incomplete.
Next week I will discuss how defects can sometimes be detected during the design phase. I hope you'll join me.
Webinar Recording: