Metrics for Quality Assurance


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 Software QA  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

Click here to learn more: https://www.indiumsoftware.com/software-testing-services/

Creation, use and analysis of metrics
In our view, for clarity, it makes sense to group metrics by type of entity involved in quality assurance and software testing, namely:
1.     Metrics on test cases
2.     Metrics for bugs / defects
3.     Metrics by task
Let us analyze in more detail each of them:
Metrics on test cases
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
Metrics on bugs
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:
1.     Requirements for function can be interpreted differently
2.     The tester is not accurately described the problem
3.     Poor surface solution to the problem (bug fix)
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:
1.     Requirements for function can be interpreted differently
2.     The tester is not accurately described the problem
3.     The developer does not wish to correct a mistake committed by them or did not believe that it is in fact a mistake. (This problem is a direct consequence of the second, arose because no precise description)
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.
Metrics by task
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.


Comments

Post a Comment

Popular posts from this blog

Software Testing: How to start

Typical day conditions, which gets the beginner: A small organization that takes orders on the development of certain software and consists of a director and several programmers, each of which performs all the possible problems - from communication with the customer to the programming, debugging, implementation and technical support. From the documentation - only "political" TK to formally meet customer requirements, and contract. With the development of the IT-market, even small by software organizations gradually feel the need to transition from natural to write code to a more or less formalized the development process. Primarily this is done to obtain predictable timing of delivery of projects, but they often come to the fore and the quality of the final product as a weighty factor in the competition. But quality can not be achieved without adequate testing. The desire to write this article appeared quite a long time as a result of reading the head of the newly crea
Read more

Why should I automate?

With  automated testing , as with many highly directional dugimi IT - disciplines, involves a lot of misconceptions. In order to avoid inefficient use of automation, should circumvent its weaknesses and maximize the benefits. Next, we will list and give a little description for the basic nuances of automation and will answer the main question of this paper - when automation is used takings . The advantages of automated testing: ·          Repeatability - all written tests will be performed always uniform, ie, excluding the "human factor". The tester did not miss the test for negligence and did not mess up the results. ·          Fast execution - automated scripts do not need to consult the instructions and documentation, it is highly time-saving performance. ·          Lower support costs - when the automatic scripts already written for their support and analysis of results is required, usually less time than to hold the same amount of manual testing . ·         
Read more

Myths about Automated Testing

The aim of this paper is the desire to give people the right idea about what exactly is " automated testing " and what it "eat". Introduction Since ancient times, mankind is engaged in mythmaking. The less there was knowledge about the natural environment, the more errors were a man and his amazing myths. With the development of science domain knowledge has expanded. But the area became more unknown. Old myths are gone, but there were new. In this article I would like to talk about automated testing and related fallacies. Some of them are more typical of upper-level managers, part - the average employee. But those and other myths interfere with the proper understanding and development of the technology itself and its successful implementation on the ground to ensure a higher quality of manufactured products. What is automated testing One of the most popular myths is that: Myth 1. Automated testing - it’s just a check of recourse. Along with him freq
Read more