All In One Guide On Defect Density – Its Importance and How to Calculate It.

A Comprehensive Handbook on defect Density:

Test Metrics can be challenging. They are the exclusive means of measurement, yet the variety is overwhelming.

You might be gathering data that doesn’t provide you with the analytics you desire. The safest approach in this situation is to follow the well-established path.

Almost every team around the world depends on defect Density to comprehend defect trends.

Today’s article is an exhaustive guide on Defect Density (DD).

Defect Density: What is it?

Let’s explore the meaning of density in its literal sense.

It refers to “the degree of compactness of a substance (Source: Google)”.

Hence, Defect Density corresponds to the compactness of defects in the application. (Essentially, it is an improved version of defect distribution.)

Applications are divided into functional areas or, more technically, KLOC (Thousand Lines of code). Consequently, bug density represents the average number of defects in a section or per KLOC of a software application.

Calculation of Bug Density

The calculation is simple.

Step #1: Acquire the necessary data: You will require the total number of defects (for a release/build/cycle).

Step #2: Compute the average number of defects per functional area or KLOC.

Formula for Defect Density with an example calculation:

Example #1: For a specific test cycle, there are 30 defects in 5 modules (or components). The density would be:

Total number of defects divided by total number of modules = 30/5 = 6. The DD per module is 6.

Example #2: From another perspective, suppose there are 30 defects for 15KLOC. The calculation would be:

Total number of defects divided by KLOC = 30/15 = 0.5. Density is 1 Defect for every 2 KLOC.

Example 2 is relevant for teams that are aware of KLOC and need a measurement based on it. However, most teams do not work with this type of statistic. Nevertheless, if needed, you can determine the number of KLOC in your application.

The Importance of Bug Density

Every metric collected by the test team conveys one of the following:

• Progress
• Productivity
• Quality

If not, you are wasting your time.

DD is the most effective means of understanding Quality.

For instance: An application with a DD of 5 per KLOC indicates better quality compared to another application with a DD of 15 per KLOC.

The higher the bug density, the poorer the Quality.

It serves two significant purposes:

• Inform: Information is power, isn’t it? Identifying the weakest areas of your application helps determine if it is “fit-to-use”.
• Call to Action: Modules with higher DD require fixing. DD aids in their identification.

Things to Avoid

#1) Do not include duplicates/returned defects

Inaccurate computation of Defect Density can mislead your team.

Do not consider duplicates/returned defects (not a bug, working as intended, not reproducible, etc.). Including them will increase the count of total defects, subsequently inflating the DD proportionally. Consequently, your defect metric will indicate poor quality, which would be a false alarm.

#2) Do not base this on data from a single day

Consider this hypothetical scenario:

On day 1, the DD is higher. This could immediately panic your team.

Therefore, wait until you have better raw material, that is, data from a few days’ worth.

Additionally, when calculating DD, consider a cumulative defect count.

In the above table, the DD from Day 2 onwards does not take into account the number of defects up to that point. It only looks at the data for that particular day.
This gives the impression that: “The defect density from day 2 is fluctuating, and there is no trend.” It also raises the question of how defect density can decrease when no action is taken regarding the defects reported the day before. Ponder upon it.

A better approach would be:

Again, if performing this calculation daily, take the cumulative defect count into account.

Potential Variations

Depending on the level of refinement your team requires, you can customize this defect metric.

• For DD of High/Critical severity issues, you can use the following formula:

Total number of High/Critical defects per KLOC or modules

• You can also do this for recurring issues per module. In this case, count only the issues that persist across builds/releases.

When does the Software become unacceptable based on Bug Density values?

Defect Density Industry Standard:

Well, this varies for every industry, application, and team. The manufacturing industry would have a specific threshold, which would differ greatly from that in the IT industry.

DD at face value indicates poor quality. However, it is the seriousness of individual defects that determines whether the product is suitable for use or not.

High DD indicates the need for a deeper analysis of defects and their consequences.

Who wouldn’t want zero defect density, right? Therefore, even though there is no specific standard, the lower the value, the better.

Final Thoughts:

• It is not a predictive count. The value of DD does not forecast the future quality of the product. It could be better or worse. Historical data will not aid in future predictions.
• During critical test stages/cycles (such as UAT), DD is calculated based on time. For instance: DD per first hour, DD per day, etc.
• When compiling defect statistics from multiple releases/cycles, defect density can be calculated per cycle or per release.
• A simple graphical representation of tabular data can be as follows:

In conclusion

Defect Density is a fundamental quality indicator. Collecting and presenting this defect metric is a reliable approach. What’s more? It is one of the simplest calculations.

I trust that this article has provided you with enough insight to begin utilizing Defect Density for deeper understanding.

Author: Swati, a member of the STH team, has composed this comprehensive tutorial.

Do you calculate defect density in your teams? If yes, do you do it per cycle, per module, or per KLOC? If not, what other metrics help you comprehend quality? Please share your comments and questions below.