As part of our Software QA Terminology series, we are exploring defect density term in this post. Defect density is typically measure per thousand lines of code (KLOC). On a high level, it can be defined as number of defects reported per thousand lines of code. However, this is not the perfect method to calculate defect density as we will see about it in this post in detail.
Defect Density is a measure showing the ratio of defects against the size of a development (Number of Defects/size). Size is typically expressed in terms of Function Points (FP), Impact Points or other ‘points’ measures such as line of code. It is typically reported as defects per 100 or 1000 points.
Period for determining defect density could be first month, first quarter or first year of project, each phase of life cycle or whole life cycle.
Why measure defect density?
Below are some points which suggest why one should calculate defect density in his/her project.
- Testing effectiveness can be measured. It also helps in determining if testing done on system is sufficient.
- This metric can be used to compare defects in software modules/components. Which in turn helps in identifying areas of improvement.
- This metric is useful in pointing towards high-risk components.
- If resources are limited, it helps in determining which areas needs more attention and inspection.
- As research indicates, pre-release defect density as reported by static analysis is a very accurate indicator of software quality.
- Calculation of defect density over a period of time helps in measuring quality improvement.
- Optional benchmark performance against the industry standards(Eg. Gartner, ISBSG) can be carried out.
- It also helps in identifying training needs to various resources.
What’s the ‘standard’?
Concerning defect density, there is no any defined standard. However, studies conducted over at Coverity Scan suggests 1 defect per thousand lines of code is generally a sign of good project quality.
What affects this metric?
Many factors affect this metric. Below are few.
- Code complexity
- The type (Eg. accepted defects, rejected defects, improvements etc.) of defects taken into account for calculation
- Duration of time which is considered for defect density calculation
- Tester/Developer skills
Hope this post would prove fruitful in explaining basics about defect density. Let us know your inputs if you are involved in churning out this metric in your project.