According to international standard ISO 14598:
Metric – this is a quantitative scale and method that can be used for measurement.
From like to add that the introduction and use of metrics is needed to improve control over the development process, and in particular on the testing process, which we will consider further.
The purpose of control testing is to obtain feedback and visualization of the testing process. Necessary to control the information collected (both manual and automatic) and used to assess the status and decision-making, such as coating (for example, coverage of the requirements or test code) or exit criteria (for example, the criteria for the testing). Metrics can also be used to assess the progress of planned activities and development budget
In our view, for clarity, it makes sense to group metrics by type of entity involved in quality assurance and software testing, namely:
Let us analyze in more detail each of them:
Passed / Failed Test Cases
Metric shows the results of the test cases, namely, the ratio of successfully traveled to fail. Ideally, the end of the project, the number of flops tests tend to zero
Not Run Test Cases
Metric shows the number of test cases that still need to accomplish in this phase of testing. Having this information, we can analyze and identify the reasons why the test was not conducted
Open / Closed Bugs
The metric is the ratio of the number of open bugs to the closed (corrected and rechecked)
Reopened / Closed Bugs
The metric is the ratio of the number of rediscovered bugs to the closed (corrected and rechecked)
Rejected / Opened Bugs
The metric is the ratio of the number of rejected bugs to open
Bugs by Severity
Number of bugs in severity
Bugs by Priority
Number of bugs by priority
Want to note that the metric "Open / Closed Bugs", "Bugs by Severity" and "Bugs by Priority" well visualize the degree of approximation of the product to achieve the quality criteria for the Bahamas. Having the requirements for the number of open bugs, after each iteration of testing, we compare them with real data, thus seeing the places where we need to add for an early goal.
Metrics "Reopened / Closed Bugs" and "Rejected / Opened Bugs" are aimed at tracking the work of individual members of groups development and testing.
First example:
Suppose we have a situation where the number of re-opened after the fix bugs is not decreasing or even increasing. This is a signal that is necessary to analyze the reasons, because This situation may indicate that:
The second example will show what is needed for the metric "Rejected / Opened Bugs":
We observe that the percentage of rejected (Rejected) bugs are very large. This may mean:
All these problems are significantly destabilize the situation in the project. Therefore, when they occur, it is recommended to hold a short conversation with the leaders of project teams to subsequently reduce the number of rediscovered reject defects.
Deployment tasks
Metric shows the number and impact of plant applications. Installing the program was described in the article The procedure for installing the new software (Deployment WorkFlow). If the number of rejected versions of the test team will be critically high, it is recommended to urgently examine and identify the causes of, and in the shortest time to solve existing problems.
Still Opened Tasks
Metric shows the number of still open problems. By the end of the project, all tasks must be closed. Under the objectives of understanding the following activities: writing documentation (architecture, requirements, plans), implementation of new modules or modifying existing on requests for changes, work on setting up booths, various studies, and much more
Metrics for different tasks may be, we have given only 2 of them. Just might be interested in the metric of the execution time and many others.
In conclusion, we want to stress that the availability of the necessary metrics and graphs showing the change in status of the project over time, will allow you to improve not only the testing process, but also the overall development and would facilitate the analysis of the project, which will in future not to allow past errors.