Chap 4 Measurement-1
Chap 4 Measurement-1
Measurement
Software Test Metrics and Measurements-
There is a famous statement: “We can’t control things that we can’t measure”.
In software projects, measuring the quality, cost, and effectiveness of the project and the
processes is most important. Without measuring these, a project can’t be completed
successfully.
Here controlling the projects means how a project manager/lead can identify the deviations
from the test plan ASAP to react in the perfect time. Generating test metrics based on the
project needs is very important to achieve the quality of the software being tested.
In the above scenario, if metrics are not followed, then the work completed by the test analyst
will be subjective, i.e. the Test Report will not have the proper information to know the status
of his work/project.
If Metrics are involved in the project, then the exact status of his/her work with proper
numbers/data can be published.
i.e. in the Test Report, we can publish:
1. How many test cases have been designed per requirement?
2. How many test cases still need to be designed?
3. How many test cases are executed?
4. How many test cases are passed/failed/blocked?
5. How many test cases have not been executed yet?
6. How many defects are identified & what is the severity of those defects?
7. How many test cases are failed due to one particular defect? etc.
Based on the project needs, we can have more metrics than the above list, to know the status
of the project in detail.
The Test Lead/Manager will gain insight into the key points mentioned below based on
the provided metrics.
Percentage of work completed.
Percentage of remaining work.
Time to complete the remaining work.
Whether the project going as per the schedule or lagging? etc.
If the project does not meet the timeline, the manager will inform the client and other
stakeholders, providing reasons for the delay in preventing any last-minute surprises.
Below is the table format for the data retrieved from the
Test Analyst who is involved in testing:
#2) Test cases not executed (%ge): This metric is used to obtain the pending execution
status of the test cases in terms of %ge.
%ge Test cases not executed = (No. of Test cases not executed / Total no. of Test cases
written) * 100.
So, from the above data,
%ge Test cases Blocked = (35 / 100) * 100 = 35%
#3) Test cases Passed (%ge): This metric is used to obtain the Pass %ge of the executed test
cases.
%ge Test cases Passed = (No. of Test cases Passed / Total no. of Test cases Executed) * 100.
So, from the above data,
%ge Test cases Passed = (30 / 65) * 100 = 46%
#4) Test cases Failed (%ge): This metric is used to obtain the Fail %ge of the executed test
cases.
%ge Test cases Failed = (No. of Test cases Failed / Total no. of Test cases Executed) * 100.
So, from the above data,
%ge Test cases Passed = (26 / 65) * 100 = 40%
#5) Test cases Blocked: This metric is used to obtain the blocked %ge of the executed test
cases. A detailed report can be submitted by specifying the actual reason for blocking the test
cases.
%ge Test cases Blocked = (No. of Test cases Blocked / Total no. of Test cases Executed) *
100.
So, from the above data,
%ge Test cases Blocked = (9 / 65) * 100 = 14%
#7) Defect Removal Efficiency (DRE) = (No. of Defects found during QA testing / (No. of
Defects found during QA testing + No. of Defects found by End-user)) * 100
#8) Defect Leakage: Defect Leakage is the Metric that is used to identify the efficiency of
the QA testing i.e., how many defects are missed/slipped during the QA testing.
Defect Leakage = (No. of Defects found in UAT / No. of Defects found in QA testing.) * 100
#9) Defects by Priority: This metric is used to identify the no. of defects identified based on
the Severity / Priority of the defect which is used to decide the quality of the software.
%ge Critical Defects = No. of Critical Defects identified / Total no. of Defects identified *
100
From the data available in the above table,
%ge Critical Defects = 6/ 30 * 100 = 20%
%ge High Defects = No. of High Defects identified / Total no. of Defects identified * 100
From the data available in the above table,
%ge High Defects = 10/ 30 * 100 = 33.33%
%ge Medium Defects = No. of Medium Defects identified / Total no. of Defects identified *
100
From the data available in the above table,
%ge Medium Defects = 6/ 30 * 100 = 20%
%ge Low Defects = No. of Low Defects identified / Total no. of Defects identified * 100
From the data available in the above table,
%ge Low Defects = 8/ 30 * 100 = 27%
Software metrics:
Software metric is a measure of software characteristics which are quantifiable or countable.
Software metrics are important for many reasons, including measuring software performance,
planning work items, measuring productivity, and many other uses.
Within the software development process, there are many metrics that are all related to each
other. Software metrics are related to the four functions of management: Planning,
Organization, Control, or Improvement.
Software metrics is a standard of measure that contains many activities which involve some
degree of measurement. It can be classified into three categories: product metrics, process
metrics, and project metrics.
• Product metrics describe the characteristics of the product such as size, complexity,
design features, performance, and quality level.
3. Data collection
5. Reliability models
9. Management by metrics
Software measurement is a diverse collection of these activities that range from models
predicting software project costs at a specific stage to measures of program structure.
Effort is expressed as a function of one or more variables such as the size of the program, the
capability of the developers and the level of reuse. Cost and effort estimation models have
been proposed to predict the project cost during early phases in the software life cycle. The
different models proposed are –
3. Data Collection
The quality of any measurement program is clearly dependent on careful data
collection. Data collected can be distilled into simple charts and graphs so that the
managers can understand the progress and problem of the development. Data
collection is also essential for scientific investigation of relationships and trends.
5. Reliability Models
Most quality models include reliability as a component factor, however, the need to
predict and measure reliability has led to a separate specialization in reliability
modeling and prediction. The basic problem in reliability theory is to predict when a
system will eventually fail.
9. Management by Metrics
For managing the software project, measurement has a vital role. For checking
whether the project is on track, users and developers can rely on the measurement
based chart and graph. The standard set of measurements and reporting methods are
especially important when the software is embedded in a product where the customers
are not usually well-versed in software terminology.
Here are the three different categories of software testing metrics: Process Metrics, Product
Metrics, and Project Metrics. Now, let’s delve into the key metrics in each category and their
importance to QA success.
Process Metrics
1. Test Case Effectiveness: Measures how well test cases detect defects.
o Use Case: Helps evaluate the quality of test cases and refine them for better
defect detection.
2. Cycle Time: Tracks the time taken to complete the testing process.
o Insight: Helps teams understand the efficiency of test runs and identify
delays.
3. Defect Fixing Time: Measures the time taken to resolve a defect from detection to
closure.
Product Metrics
1. Number of Defects: Indicates the quality and efficiency of the software product.
o Use Case: Prioritizes fixes based on severity to ensure critical issues are
addressed first.
3. Passed/Failed Test Case Metrics: Provides data on the stability and functionality of
the software.
o Formula for Passed Cases: (Passed Test Cases / Total Test Cases) x 100
Project Metrics
Project metrics provide insights into the broader scope of the testing process, focusing on
team and resource efficiency.
1. Test Coverage: Measures the percentage of tested functionalities.
Calculation:
Valid Defects: 15
Fixed Defects: 12
Deferred Defects: 5
Calculation:
Object oriented metrics capture many attributes of a software product and some of them are
relevant in testing. Measuring structural design attributes of a software system, such as
coupling, cohesion or complexity, is a promising approach towards early quality assessments.
There are several metrics available in the literature to capture the quality of design and
source code.
Coupling Metrics
Coupling relations increase complexity, reduce encapsulation, potential reuse, and limit
understanding and maintainability. Coupling metrics require information about attribute
usage and method invocations of other classes. These metrics are given in Table 10.1.
Higher values of coupling metrics indicate that a class under test will require a higher
number of stubs during testing. In addition, each interface will require to be tested
thoroughly.