Defect Analysis
Learning From Defects
Defect analysis can provide a vast wealth of information to help you focus your improvements in not just the area of software quality but also in areas such as your development process and developer training.
Root Cause Analysis
It's always good to not just understand a defect but to know how and why it was introduced as the on-going desire is always focused on defect prevention rather than mitigation.
You might choose to use the Lean "5 Whys" approach as a means of determining the root cause but however you go about doing that it will always prove a valuable exercise as this is the means by which you will likely identify a future avoidance or early detection mechanism.
Orthogonal Defect Classification
Orthogonal Defect Classification (ODC) is a rather grand sounding name for the technique of classifying defects into distinct categories so that you can count them in order to prioritise how and where to focus your improvement/prevention efforts.
ODC can be used for both in-flight and retrospective project analysis. You can even use it for comparing projects if the nature of the project domains is not too dissimilar.
Defect Hotspots
The location of a defect (perhaps which software component the defect was detected in) is a simple means of classification in itself.
When counting your defects you may notice that particular types of defect always occur in particular areas or locations and therefore stand out as hotspots. Recurring themes may begin to emerge and root cause analysis should enable you to eliminate such problems via a simple process change, an additional review on your checklist, developer training, alternative tooling etc.
Improving Testability
Some defects repeatedly creep in because of a lack of testability and so your mitigation should be to re-architect your design to improve testability and thereby enable earlier detection and remediation when you can't do anything to avoid such defects.
Definition Of Done
To simplify the process of analysing defects you might want to ensure your definition of done includes tasks such as root cause analysis and orthogonal defect classification. That way, when you come to analyse your defects, perhaps at the end of an iteration or mid-way through a development phase, you will already have much of the valuable data you need to act upon.
Making time to analyse defects is always time well spent and hopefully you won't have too many to analyse.😒
What are your defects trying to tell you?
Thank you for liking this page.
Tim Simpson
25th May, 2021
#LifeAtCapgemini