The term 'Defect Prevention' (DP) relates to defect analysis and preventive action planning related to defects found in various streams of project activities. Typically defects can be review defects or testing defects (there are other types of defects as well - For example, configuration defects or other forms of defects that are not captured during reviews or testing).
What can be our approach to DP? It can be something that includes a systematic way of collecting and analyzing defects and preventive action planning. Also, this approach includes the frequency of performing DP and a clear definition of ownership so that DP happens as planned. The objective of DP is to make sure that a significant number of those defects do not occur in future.
Creating and executing test cases, test automation, and code quality checks are meant for ‘Defect Detection'. Not for ‘Defect Prevention’.
So, how do we do DP? Well, we can do DP by gathering data on all defects, categorizing them, analyzing them and deriving certain conclusions. Based on these conclusions we decide on preventive actions and implement them.
If we do not derive and implement preventive actions, all we accomplish is a pure 'Defect Analysis' (also known as Bug Analysis). DP requires you to travel an extra mile (in terms of identifying and implementing preventive action plan) after you complete Bug Analysis.
80/20 principle is adopted as one of the DP techniques. When you analyze test defects you perform ‘Pareto Analysis' to understand the distribution of defects. Based on your findings, you come up with action items that help you prevent 80% of defects. There are other techniques too.
Agile teams go through iteration-end retrospectives. How can DP techniques help them perform better? What has been your experience? Do you follow DP techniques? Let us discuss.
No comments:
Post a Comment