Defect Density is the number of confirmed defects detected in software/component during a defined period of
development/operation divided by the size of the software/component.

It enables one to decide if a piece of software is ready to be released.

The ‘defects’ are:

• confirmed and agreed upon (not just reported).
• Dropped defects are not counted.

The period might be for one of the following:

• for a duration (say, the first month, the quarter, or the year).
• for each phase of the software life cycle.
• for the whole of the software life cycle.

The size is measured in one of the following:

• Function Points (FP)
• Source Lines of Code

Defect Density = Number of Defects/Size

Defect density is counted per thousand lines of code also known as KLOC.

size of release can be measured in terms of line of code (LoC)

Standard for defect density

However, there is no fixed standard for defect density, studies suggest that one defect per thousand lines of code is generally
considered as a sign of good project quality.

Advantages of defect density

• It helps measure the testing effectiveness
• It helps to differentiate defects in components/software modules
• It is useful in identifying the areas for correction or improvement
• It is useful in pointing towards high-risk components
• It helps in identifying the training needs to various resources
• It can be helpful in estimating the testing and rework due to bugs
• It can estimate the remaining defects in the software
• Before the release we can determine whether our testing is sufficient
• We can ensure database with a standard defect density

Uses

• For comparing the relative number of defects in various software components so that high-risk components can beidentified and resources focused towards them.
• For comparing software/products so that quality of each software/product can be quantified and resources focusedtowards those with low quality.