The Practical Guide to Defect Prevention

Conclusion

The example taxonomy is fairly broad, and it has attributes addressing many assumptions of behavior and dimensions of how to look at a defect. Peaks in various attributes or combinations of attributes may validate assumptions of the kind of error developers are making or may target subsets of defects for more in-depth analysis. Comparing frequencies by team may identify both good and bad results. These results can then be analyzed to discover local best practices or to correct local bad practices. In large software projects, you can’t afford to perform in-depth analysis of every bug, communicate the results to every developer, and expect every developer to remember everything. Defect taxonomies are lower overhead than in-depth analysis ...