In a software testing field, there are such concepts as product quality and evaluation of its usability and accessibility.
But clients should understand and ensure software testing is performed thoroughly.
In other words, a level of software testing should be evaluated with the help of certain criteria, in the same way as many other activities.
[highlight dark=”no”]In software testing, such criteria are called QA metrics.[/highlight]
Such metrics are some kind of various rates and data that can help to not only see the current state of a project’s progress but also find correct ways of improving/increasing a level of software testing efficiency.
Metrics affect all most important fields of testing — from product quality assurance to efficiency of a project group (from a development field to a management field).
This article will be devoted to describing such a testing metric as test coverage.
Test coverage is a level of covering a software code that is being tested or its requirements with tests.
[highlight dark=”no”]The more tests are created, the higher will be the level of test coverage on any project.[/highlight]
But we should still understand that it’s impossible to cover everything since you can’t test every function of software.
Evaluation of test coverage consists of several methodological approaches:
- Requirements coverage;
- Code coverage;
- Test coverage based on analyzed data of a control flow.
Let’s analyze each approach separately.
Requirements coverage
This metric shows a current level of covering all established software requirements with tests. It’s most accurate when the established requirements are atomic.
This metric is calculated according to the following formula: Test coverage = (number of claims covered by test cases/total number of claims)x100%.
To test this test coverage, we should divide all requirements into separate items and then link each item with the test cases that test it. Test cases are useless if they can’t test certain requirements for software.
[highlight dark=”no”]Each connection created between test cases and requirements is called a traceability matrix.[/highlight]
If we analyze such a connection, we can easily get an answer to such questions: what requirements are tested by certain test cases, and what requirements need creating or/and editing of available test cases.
Some requirements may comprise unnecessary test cases.
Code coverage
The next metric shows the number of software code lines that are involved during test case execution.
The metric’s logic is calculated according to the following formula: Test coverage = (number of lines of code covered by test cases/total number of lines of code)x100%.
To understand what lines were executed during the execution of established test cases, we should use special tools that help to find the code lines that are needed for calculating test scripts.
Testing of test coverage is performed by white-box testing on the basis of unit, system, integration methods of testing.
Test coverage based on analyzed data of a control flow
It’s one more method of software testing with complete access to software code but it helps to test the ways of software implementation.
To cover flow data, special test scripts should be created.
To test control flows, you should plot its graph — Control Flow Graph.
Conclusion
It’s definitely a few examples of all metrics that are used to evaluate a software testing process. There are numerous special methods, from a rate of requirements stability to efficiency of tests and test suites.
They are not only aimed at improving the quality of software development and software testing but also significant improving an end user’s level of satisfaction from a product.
0 Comments