Metrics for Testing- Guide to Quality Assurance
Table Of Contents
- 1 Introduction
- 2 Significance of Metrics in Testing
- 3 Types of Software Testing Metrics
- 4 Test Metrics Life Cycle
- 5 Analysis:
- 6 Communicate:
- 7 Evaluation:
- 8 Report:
- 9 Testing Metrics: What they are and how they work
- 10 Base Metrics
- 11 Derived Metrics
- 12 Test Planning
- 13 Test Effort
- 14 Test Effectiveness
- 15 Test Coverage
- 16 Test Economics Metrics
- 17 Test Team Metrics
- 18 Test Execution Status
- 19 Effectiveness of Change Metrics
- 20 Final Thoughts
In the current scenario, quality control is the luring force behind the success and popularity of software products, which has drastically amplified the requisite of taking efficient measures for quality. Thus, software testers are applying a solid drive to gauging their aims and efficacy, which is possible by using various metrics for testing and Key Performance Indicators (KPIs).
Software testing metrics are the quantifiable indexes of the testing procedure, quality, productivity, progress, and overall health. The purpose is to boost the effectiveness and conclusiveness of the software testing operation and support the fabrication of better resolutions for future testing by delivering precise data about the test proceedings. A metric expresses the grade to which a system or a process possesses a given criterion in numerical stints.
The intent of collecting test metrics is to use the data to improve the test process. This includes finding tangible solutions to the following:
- Time and expense required for the test
- Category of the bugs. The number of them found, fixed, reopened, closed, deferred, or unreported
- Grade and caliber of the testing operation
- Adequacy of the test effort
- Testing bandwidth of the current release
Significance of Metrics in Testing
Metrics decide the software’s quality and performance. Developers may utilize the appropriate software testing standards to enrich their productivity. A few critical software testing standards are given below:
- Testing benchmarks assist in deciding what kinds of refinements are needed to generate a high-quality, flawless software product.
- Making reasonable jurisdictions regarding the various testing facets that succeed, like project scheduling, design plan, and expense estimations.
- Examining the prevailing technology or operation to determine if it demands further changes.
Types of Software Testing Metrics
Software testing metrics are split into three groups.
- Process Metrics: The process metrics outline the characteristics and performance of a design. These features add to the SDLC (Software Development Life Cycle) procedure’s enhancement and conservation.
- Product Metrics: A product’s design, size, quality, performance, and complexity are delineated by the product metrics. Developers can amend the caliber of their software development by employing these features.
- Project Metrics: Project metrics are employed to evaluate the generic quality of a project. It estimates the design resources and deliverables and decides productivity, cost, and possible flaws.
It is crucial to ascertain the befitting testing measures for the operation. Some of the points to keep in mind are the following:
- Choosing the target audiences precisely before creating the metrics.
- Outlining the objective for which the standards were developed.
- Formulating measures based on the project-specific necessities.
- Estimating the financial gain chummed with every statistic.
- Matching the measurements to the design life cycle for achieving the best results.
A substantial advantage of automated testing is that it allows testers to finalize more tests in less time while covering a large composition of variations that would be practically tough to compute manually.
You can read more about metrics in SDLC here: Metrics in SDLC: Let the Truth Prevail | Testsigma
Test Metrics Life Cycle
- Recognizing the most appropriate metrics for testing.
- Defining the adopted QA standards.
- Training the software testing team on the data points to be collected for processing the recognized metrics.
- Informing the testing team and the stakeholders of the requirements.
- Capturing and then verifying the data.
- Using the collected data for evaluating the value of the metric.
- Creating a sound and compelling inference for the paper.
- Gathering potent inputs from the stakeholders and representatives based on the information. Distribution of these reports to the representatives and stakeholders.
Testing Metrics: What they are and how they work
Here, we will elaborate in detail on various software testing benchmarks.
Fundamental QA metrics, also known as base metrics, are a composition of absolute numbers collected by analysts throughout the development and execution process. Some of them are :
- Total number of test cases
- Total number of passed, failed, and blocked test cases
- Total number of defects and critical issues reported, accepted, rejected, and deferred
- Total number of planned and actual test hours
- Total number of bugs discovered after shipping
Base metrics are the fundamental starting point but only placing those values is not enough. Testers should also derive some sound benchmarks using mathematical computations.
Only tabulating the absolute numbers collected by analysts and testers produces more confusion than solutions. Hence, we can dive deeper into solving the glitches and flaws in our software testing course using the derivative metrics.
The following metrics are derived to facilitate test planning:
- Passed test case percentage = Total number of passed test cases / Total number of test cases x 100%
- Passed test case percentage = Total number of failed test cases / Total number of test cases x 100%
- Blocked test case percentage = Total number of blocked test cases / Total number of test cases x 100%
- Fixed defects percentage = Total number of defects fixed / Total number of defects reported x 100%
- Accepted defects percentage = Total number of defects accepted as valid / Total number of defects reported x 100%
- Defects rejected percentage = Total number of defects rejected as invalid / Total number of defects reported x 100%
- Defects deferred percentage = Total number of defects deferred for future / Total number of defects reported x 100%
- Critical defects percentage = Total number of critical defects / Total number of defects reported x 100%
- Average time to repair defects = Total time taken for fixing the bugs / Total number of bugs found
Testing effort standards will answer the question, “how long or how many or how much?” They are practiced to establish baselines for test planning. However, these metrics are mean values where 50% of the values fall over the mean and 50% under.
Some of these specific metrics are:
- Tests run per time period = Total number of tests run / Total time taken
- Test design efficiency = Total number of tests designed / Total time taken
- Test review efficiency = Total number of tests reviewed / Total time taken
- Defects per test hour = Total number of defects / Total number of test hours
- Bugs per test = Total number of bugs found / Total number of tests
- Time to test a bug = Total time taken between defect fix to retest for all defects / Total number of bugs found
Test effectiveness finds a solution to “how good are the tests?” It evaluates the bug-finding quality and ability of a test set. Test effectiveness measures generally express the difference between the total number of defects reported by the QA team and the overall defects found in terms of percentage.
- Test effectiveness using defect containment efficiency: The higher the test effectiveness, the better the test set and the lesser the long-term maintenance effort will be. For instance, if the test effectiveness is 70%, it concludes that 20% of the defects are removed from the testing operation.
- Context-based test effectiveness using team assessment: Defect containment efficiency metrics do not come in handy in the following cases:
- Already mature product
- Buggy and unstable product
- Lacking enough tests due to constraints of time or resource
In such cases, another way to estimate test set effectiveness is using a context-based approach.
For instance, in a particular context, the QA team decides that a befitting test set needs to cover high-risk demands adequately.
Read this blog to understand why quality assurance is of paramount importance: Why The World Doesn’t Need QA Engineers (But still requires quality assurance) | Testsigma
Software quality metrics estimate the fitness of the application under the testing process. The following core block of standards that need to be analyzed revolves around the testing coverage. Test coverage benchmarks gauge the test exertion and help determine the operations’ significance.
Given below are some crucial test coverage benchmarks.
Test execution coverage:
This provides a model of the comprehensive tests administered compared to the unsettled test runs. It is typically expressed as a percentage.
Test requirements coverage:
The number of demands covered by the total amount of scoped needs for a release, design, sprint, or project must be divided and analyzed to achieve a high-level prospect of the requisites having test coverage.
Test Economics Metrics
Infrastructure and tools contribute to the expense of testing. Testing systems do not have fathomless financial resources to spend. Thus, estimating how much you can spend and how much you indeed wrap up spending is eventful.
Here are a few test economics measures that can provide insight into budget planning:
Total allocated costs for testing:
It refers to the amount that QA directors and CIOs have calculated for all testing exercises and resources for single dev projects for the entire year.
Actual cost of testing:
It refers to the real money that went into the testing operation.
It is assumed that all testing sets are equal in complexity. For illustration, if the budget is $1000 and includes testing 100 necessities, the cost of trying a requisite is $10. These values are substantial as they help estimate future projects and systems budgets.
The variance between the actual and planned costs is referred to as budget variance.
It is the difference between the actual time taken to complete tests and the planned time.
Cost per bug fix:
It refers to the amount of effort spent on a defect per developer.
However, the cost of a bug fix is 10 * $60 = $600; if a developer spends 10 hours fixing a defect, their hourly rate is $60.
Cost of not testing:
All the finances that went towards the rework equate to the cost of not testing If a block of new features went into production but claimed rework. The expense of not testing can also be silhouetted to a more subjective value, similar to a person’s perspective.
Some examples of a subjective cost of not testing are as follows.
- More client care calls and service requests.
- Productive outages
- Loss of user/ client trust
- Loss of client fidelity
- Poor brand awareness
Test Team Metrics
These can be exploited to deduce if work allotment is uniform for each test squad member and to check if anyone needs added process/ project knowledge expositions. These criteria should never be used as an erudition to attribute fault.
- Distribution of defects returned per team member
- Distribution of open defects for retest per test team member
- Test cases allotted per test team member
- Test cases executed by test team member
Usually, histograms or pie charts are created to get a quick snap of the job assignment. It allows the testing manager to determine the cause and take remedial actions if demanded.
Test Execution Status
Test execution snap chart shows the complete implementations disposed of as passed, failed, blocked, incomplete, and unexecuted for easy engrossment of the test sprint status.
These charts are great optical apprentices for the daily status huddle because raw figures have a high chance of sagging through people’s brains. The rising and contracting bars captivate attention and impart advancement and speed much more effectively.
- Test Execution Status Chart
- Test Execution/ Defect Find Rate Tracking
- Test Execution Tracking and Defect Find Rate Tracking
The theoretical curve is plotted using these cumulative test execution rates and defect counts. Compared to the raw figures, these charts shall signal early that the testing course needs to be changed if the targets need to be reached.
Effectiveness of Change Metrics
Software undergoes a handful of frequent changes. Changes typically invoke new deformities, catalyze timelines to sag, reduce operation robustness, and endanger quality. Embodied modifications must be watched precisely to conclude their concussion on the robustness and stability of the existing product.
The following benchmarks can help in a better understanding of concussions.
Effect of Testing Changes:
It numerically refers to the total number of defects that can be put down to changes. This could denote ensuring defects have been affected and fix visions attached when they are reported to the development team.
Defect Injection Rate:
It is numerically the total number of test problems attributable to the changes.
For illustration, if ten changes are made, and it is found that 30 defects are attributable to them, it means that each change ended up edging in 3 defects. Hence the defect injection rate is 3 per change.
Grasping this figure will help forecast the number of defects that can be anticipated per new change added to the system. This allows test squads to exploit retrospective conventions strategically to understand their capacity to pinpoint and fix bugs coming from recent changes.
Software testing metrics and crucial performance indexes enrich the course of software testing. From securing the precision of the multiple tests carried out by the testers to authenticating the class of the product, these benchmarks play a pivotal purpose in the software development lifecycle.
Hence, by enforcing and executing these testing standards and performance pointers, the effectiveness and accuracy of the testing efforts can be exponentially increased to get a phenomenal grade for software products.