Uncategorized

# Defect Density

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.

• 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

1. 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.

1. 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? 