That’s right, you read the title. Defects are good and just like all human beings, no software in this world is perfect. And just like us humans, the only thing that distinguishes the good and the bad is how you deal with the defects. Otherwise, defects are good. In this article, we’ll explore the bright side of defects, one which you probably haven’t been told before.
Prevention of Future Problems
If the defects are analyzed from a preventative point-of-view and adequate information is obtained, then this is probably the greatest value a defect can provide. This kind of analysis requires that the defect's point of origin can be identified and tracked. For preventive analysis to show its effect, it's important to have a correctable process in place. Defects should be categorized in ways that can be meaningful for future improvements. All of this can be facilitated by defect management tools. Examples of the categories include:
- Computational defects
- Data validation defects
- Usability defects
- Logical decision defects
- Requirements defects
- Design defects
- Presentation defects
Tracking of Relative Improvement
Defects can provide some meaningful information as we’ve discussed. But this is not only limited to solving just future problems. Defect management tools generate metrics that can help quantify relative improvement when an organization is working on a series of projects. This can help gauge the team’s performance as well. DDP (defect detection percentage) is a very useful indicator in this matter. It’s the number of defects found in testing divided by the number of defects found over the defined life of the product. So, for example, if defects found in all
Project Status
Although the release date of a product is already decided, defect stats can give testers, developers, and management a quantitative idea of when the product will actually be fully ready to be rolled out in the market. Let’s suppose, for instance, you only have a couple of days until the project deadline and testers have found 100 defects to date, 5 of which are severe and will require several more days. This kind of information should be of great value to management as it is a key piece of information to judge the readiness of the application. Besides, the location of defects can reveal opportunities to focus resources. In some cases, a phased implementation may be a contingency if an area of an application is non-critical and high defects exist in that area. Usually, when this type of information is ignored by management in favor of meeting a deadline, a high-risk situation exists. The result of proceeding with implementation in the face of high unresolved defects is a toll taken in rework, lost customers and high inefficiency.
Conclusion
By looking at defects in light of these three purposes, we can see how something as annoying and frustrating as defects can have a good purpose. It certainly doesn’t mean that you should have a lax attitude towards defects. They cost money, delay projects, and even place lives at risk in some cases. However, since each defect costs money and time, let's learn the most we can about defects so we can prevent them or at least find them earlier in the software development process.
