In recent years, we have seen a significant transition of software development process from traditional waterfall to iterative / Agile / SAFe and list goes on. No mater what software development process team follows, ultimate goal is to ensure product stability and and quality of the product release by release, which normally measured and tracked with different software Quality Metrics. If we look back, traditional software development processes like waterfall etc with longer release cycle ( approximately 6 month per release) and when Managers has sufficient time to work on different software quality attributes, to monitor the quality of the product, but in present scenario when product delivery cycle is going shorter and shorter, it is going more difficult to monitor huge number of Quality Metrics.
No doubt, we have brilliant tools, which can calculate any number of Quality Metrics for every Release Cycle, but the bigger picture is that to which Metric should Manager and Team should focus on. Practically, working and focusing on limited Quality Metrics, makes every ones life easier, but challenge here is to select better Quality Metrics, which not only gives a clear picture of the product quality but also could be used against your completion in the market.
Among, many proposed software quality attributes, from Organisational Level to Team Level, One metric ‘Defect Density’ found to be very effective. This metric fits for every layer of the product development, and can clearly depict the quality index of the Product pretty accurately.
As per literature, and various resources, Defect Density can be defined as “Agreed Open Defect per Thousand Line of Code.”. This metric normally calculated per Release Candidate branch of code base. Lets say, team is working with 2 weeks sprint cycle, and product rolling for production every fortnight. So at the end of every sprint Defect Density can be calculated as under :
1. Identify Code Size in KLOC (Can easily obtained for RC Branch), lets say it to be ‘K’
2. Identify Count of “Agreed and Existing Open Defects”, at the end of the sprint, lets say it to be ‘C’
Then Defect Density of code, at the end of Sprint ‘S’, would be = C/K
Recording this metric, sprint by sprint will give you a trend and shows how stable and good quality product your team is producing. The more steady and straight line touching the x-axis always a win-win situation for Client / Management and yes Team itself.
Lets take an example, for sprint 1 to sprint 10, defect density comes out to be as in table,
then the graph will clearly depict the defect density trend of the product, sprint by sprint.
For majority of the cases, Defect Density is calculated for defect raised by ‘Support Team’ or ‘Customers’ only, which suggested to be in the range of 0 to 0.5, and not more than 0.7
Defect posted by internal QA team, can be added in the defect count, but recommendation is to consider this to be Defect Density with different nomenclature, ie. ‘Defect Density (Internal).