How should one measure Defect Density?

Question

Is there a standard way of measuring Defect Density? Most sites online state that it should be measured as:

number of defects discovered / the code size

My questions are:

• Should defects "fixed" during the period be subtracted from the defects discovered?
• What should one do with the defects one decides to fix in the following release, due to lack of time? Should these backlog defects be added into the next release's density?
• KLOC in the denominator is probably not a good measure if it has been proven that the code is unnecessarily bloated up due to heavy duplication. How should one factor that in?
• Can one correlate the Churn in a particular period of time, and the existing backlog of defects for a particular module, to the number of defects created/discovered as a result of the Churn

Our ultimate goal is to be able (a) to compare our defect density against industry standards (b) to identify modules which are fragile and more buggy and deserve more attention (c) to use a consistent metric in order to draw a trend line demonstrating improvement in the quality of a module over time

Answer 1

Defect Density is the number of confirmed defects detected in software/module during a defined period of development/operation divided by the size of the software/module. ('defects(confirmed and agreed upon (not just reported))).

Defect Density: Defect Density = Defect/unit size

Ques may arise here is, what is this unit size actually meant for. Unit size=Size is typically counted either in Lines of Code or Function Points. Being a good coder you should be confident enough that there are no duplication in your coding which could bloated up your code size.

Ex: Suppose 10 bugs are found in 1 KLOC Therefore DD is 10/KLOC

Answer 2

Defect Density is used for measuring the quality of the code/ module/ requirement/ product. Yes the standard for measuring the same is Defect Density = Number of Defects/Size

but here if we use size as KLOC (Thousand lines of code) or FP (Function Points) then it may be difficult to calculate the same and sometimes for the customer (or some take holders) it doesn't make any sense. So, we should consider the following points too while calculating Defect Density.

1. Number of Defects should be calculated by adding all defects related to code (these should include Review Defects, Internal Bugs and Client/UAT bugs too) because all bugs are related to code and hence should be part of Defect density.
2. Equalized the Defects count based on their Severity before adding them, this gives more accurate result and it's a standard too. One can consider it as Critical Bug = 5, High = 3, Medium = 1, Low = 0.5. This is sometimes referred as Weighted Defect Density, but is more precise in results.
3. Size should not be limited to only Lines of Code or Function Points. It can be no. of requirements too. Easiest and effective way is to take size as time spent in coding (this should not include Code Review, Coding Rework effort). Thus, Defect Density can be considered as Defects per 100 Man Days of effort spent in coding and if you have a project goal specified, then you can see if this meets your goal or not.

This is an effective and easy way of calculating Defect Density, with the period of time you can see if you are improving or not.

Answer 3

I'm guessing that Defect Density is used in order to detect the rate at which your programmers are generating defects, whereas subtracting fixed defects is to do with the number of complaints made by your customers/end users.

Of your goals, (a) seems unsound, (b) is hugely incisive and will pay dividends and (c) may induce false optimism.

You should really be aiming for Zero Defects and you should, for metrics purposes, ignore bugs found and fixed before release.

Answer 4

Defect is basically,when the product is shipped to customer after that any functionality is not working or you can say deviation from user requirements, you can't measure defect but you can take some measures to prevent from getting defect,it can be done through different testing ways,some of important one's you will find below :

• Smoke Testing
• Sanity Testing
• Black-box Testing
• White Testing
• Load and Stress Testing

You should have complete knowledge what your client is asking from you,it will help you to prevent you from defect.

Answer 5

total number detected defects in your developed software divided by size of your software in line of code . it is calculated in KLOC ,it means it is multiply by 1000 
for example
defects found are 12
size is 2000
defect density= defects/size
answer=.006
it is calculated in kloc so .006*1000=6 so defect density is 6