What is Defect Density?
Defect density is the number of defects detected per lines of code or per module. It is a measure of the quality of the code — the better the software quality, the lower the density.
Most teams calculate defect density as the number of defects per thousand lines of code (KLOC).
A real-world example - if you find 15 bugs in 25,000 lines of code. The defect density will be (15x1000) ÷ 2500 = 0.6 per KLOC.
This number means that if the same developers write another 50 thousand lines of code (50 KLOC) of the same complexity, that code will most likely have 30 bugs (50 x 0.6).
Some teams also count defect density as the number of defects per module.
For example, if you find 25 bugs in 10 modules, the bug density will be 25 ÷ 10 = 2.5 per module.
Factors affecting Defect Density
Complexity
As the complexity of code increases, the defect rate could increase significantly.
Skill level
Low-skilled developers tend to have a very high defect frequency.
Defect Type
For the same set of developers, the UI bugs rate will be the same. However, the density of security bugs will be different.
Advantages of Defect Density
Validate Testing Quality
You can estimate the number of defects expected after testing based on the developer's track record. If the number of defects found is significantly less than expected, it probably means the testing has not been thorough.
Save Testing Resources
If the number of defects found in a module is more than expected, you can abort its testing and resend it to the developer for an overhaul.
Compare Developer Efficiency
A developer with a lower defect density is better than one with a higher number. Publishing these numbers can create a competitive environment and also useful at the time of salary appraisal.
Disadvantages of Defect Density
Defect density is heavily dependent on complexity. And complexity is challenging to quantify, which means comparing two numbers is difficult.
A bug density of 0.6 per KLOC in a module that does complex multi-time-zone scheduling is perhaps much better than 0.4 per KLOC in a code that does simple CRUD (Create, Read, Update & Delete) operations, code in which you don't expect any bugs.
Conclusion
Defect efficiency is used to gauge code quality. Sometimes, the numbers may not show the correct picture, so remember to use them in context. And, don't forget the big picture.