Software testing defect metrics

Posted on Apr 11 2010 - 5:27pm by Raj

Software testing defect metrics is used to measure the quantification of a software related to its development resources and/or development process. It is usually responsible for quantifying factors like schedule, work effort, product size, project status and quality performance. Such metrics is used to estimate that how much of more future work is needed to improve the software quality before delivering it to the end-user.
This process of testing defect metrics are used to analyze the major causes of defects and in which phase most of the defects are introduced. Below we are going to discuss some key software testing defect metrics:

Defect Density:
The defect density is measured by adding up the number of defects reported by the Software Quality Assurance to the number of defects that are reported by the peer and dividing it by the actual size(which can be in either KlOC, SLOC or the function points to measure the size of the software product).

Test effectiveness:
There are several approaches towards analyzing test effectiveness, one of them is t/(t+Uat) and in this formula “t” is the total number of defects reported during the testing, whereas Uat means the total number of defects that are reported during the user acceptance testing.

Defect Removal Efficiency:
It’s a sleek process that includes the total number of defects removed divided by the total number of defects inject to multiply by 100 during the various stages of SDLC.

Effort Variance:
Effort Variance can be calculated as {(Actual Efforts-Estimated Efforts) / Estimated Efforts} *100.

Schedule Variance:
Just like above formula it is similarly calculated as.
{(Actual Duration – Estimated Duration)/Estimated Duration} *100

Schedule Slippage:
When a task has been delayed from its original baseline schedule then the amount of time that it has taken is defined as schedule slippage. Its calculation is as simple as.
(Actual End date – Estimated End date) / (Planned End Date – Planned Start Date) * 100

Rework Effort Ratio:
(Actual review effort spent in that particular phase / Total actual efforts spent in that phase) * 100

Requirements Stability Index:
{1 – (Total number of changes /number of initial requirements)}

Requirements Creep:
(Total Number of requirements added/Number of initial requirements) * 100

Weighted Defect Density:
(5*Count of fatal defects)+(3*Count of Major defects)+(1*Count of minor defects)
Where are the values 5,3,1 corresponds to the severities of the detect?

And at the end we’d like to tell you that purpose of metrics isn’t just to measure the software performance but also to understand the progress of the application to the organizational goal. Below we will discuss some parameters of determining metrics of various software packages:

• Duration
• Complexity
• Technology Constraints
• Previous Experience in Same Technology
• Business Domain
• Clarity of the scope of the project

And one of the interesting and beneficial approaches is using the GQM (Goal.
-Question-Metric) technique. Th’s technique consists of three stages: A Goal, a set of questions, and a set of corresponding metrics and therefor it’s a hierarchical structure that specifies the purpose of measure, the object that has to be measured, issues that need to be measured, and viewpoint from which the measures are taken.

About the Author

Leave A Response