Defect Density can have more number of defects that is software while having an operation developed that is divided by the software. This development is to decide a portion of software is ready to be released.
How to calculate Defect density?
It is calculated by the formula
Defect Density = Defect count/size of the release is the formula
Defect density example
Consider we have 3 modules which is integrated in our software product. There is every which has the following number of bugs like
- Module 1=10 bugs
- Module 2=20 bugs
- Module 3=10 bugs.
Here the total bugs are
10+20+10=40
The total number of line of code for each module is
Module 1=1002 LOC
Module 2=1200 LOC
Module 3=450 LOC
Total line of code=1002+1200+450=3752
Here defect density will be calculated
Defect Density = 40/3752=000933 defects/loc = 93.3 defects.
We don’t have standard for bug density, studies that can have a defect per thousand lines of code will be considered as a sign of good project quality.
Why bug density is important?
Each and every metric that test team collects one of the following
- Progress
- Productivity
- Quality
The higher bug density the poorer will be the quality
It serves two purposes
1 Inform: Here information is power, knowing the weakest areas of our application helps us to decide if it is fit to use or not
2. Call to Action: A module with higher DD it also identify them.
Advantages of Defect density:
- It supports to measure the testing effectiveness.
- It helps us to find the difference between defects in components/software modules
- It is useful to identify the areas for correction or improvement.
- It is always useful in pointing towards high risk components
- It helps in identifying the training that needs to various resources.
- It is supporting in calculating the testing and rework due to bugs.
- This will be having estimation of the remaining defects in software
- It is determined whether our testing is sufficient.
- We will be sure to make sure the database with standard defect density.
We should not do in defect density
- Don’t take into account duplicates/returned defects where inaccurately computed Defect density which can mislead the team.
We should not increase or include the duplicates or may be returned defects. It increases the total no of defects which means the DD may increase proportionally. Defect metric will suggest the poor quality which would be a definite false alarm.
- We should not do based on the present data
On that day the DD will be higher. This will send the team into a panic mode immediately. So we have waited few days worth a data.
When we will be calculating the defect density we want a cumulative defect count. In the above that DD take into account the number of defects so far. It will be giving the impressions that the defect density will not have into account the number of defects so far, the defect density from 2nd day is decreasing and increasing the better way to do this is
It we are doing this daily take a cumulative defect count.
What is defect based software testing technique?
There is a defect based software testing process that is used to prepare test cases on defects detected in the product. This process will not be considered the specification based technique that follows use case documents. Testers will be prepared their test cases based on the defects. The technique can be conducted where in this strategy testers may prepare their test cases based on the defects.
Questions
1. What is defect density?
2. What are advantages of defect density?
