Definition level, priority and state _ software testing of defects

Definition and main types of software defects

We analyze software defects, the so-called "software defects", that is, the computer software or programs in the existence of some kind of damage to the normal operating capacity of the problem, error, or hidden functional defects. In general, the attributes of software defects include defect identification, defect type, severity of defect, defect priority, source of defect, cause of defect and so on.

Software defect analysis, the main software defects can be divided into the following types:

(1) Unreasonable design;
(2) Function, feature is not implemented or partially realized;
(3) Operation error, including operation interruption, system crash, interface confusion, etc.
(4) Inconsistent with the demand, the actual results and expected results when the implementation of TestCase;
(5) The user can not accept other problems, such as the access time is too long, the interface is not beautiful;
(6) The software realizes the function that the requirement does not mention.

The grade, priority and state of software defects

There are four levels of software defects: fatal (Fatal), severe (Critical), General (Major), Tiny (Minor).

Class A-fatal software flaw (Fatal): Causes the system or application crashes, freezes, the system hangs, or causes the data to lose, the main function completely loses, causes this module and the related module abnormity and so on the question. such as code error, dead loop, database deadlock, database connection error or data communication error, not considered abnormal operation, function error, etc.

Class B-Serious error software defects (critical): The main function of the system is lost, the data can not be saved, the system's secondary functions are completely lost. The problem is limited to this module, which causes the module function to fail or exit unexpectedly. such as fatal error declaration, program interface error, database tables, business rules, default values are not added integrity constraints

Class C-Generic error software defect (major): Minor features are not fully implemented but not used. If the information is not accurate, or user interface is poor, long operation time, module functional part of the failure, etc., print content, format error, delete operation did not give a hint, the database table has too many empty fields, etc.

Class D-Minor bugs software defects (Minor): Make the operator inconvenient or encounter trouble, but it does not affect the operation and implementation of the function, such as typos, interface is not standardized (font size is not uniform, the text arrangement is not neat, can enter the region and read-only areas do not have a marked distinction), the auxiliary description is not clear

Class E-The software flaw in the proposed problem (Enhancemental): questions raised by the person to improve the test object or the tester's suggestions, questions.

The common software defect prioritization methods can be divided into: immediate resolution of P1, high priority P2, normal queuing P3, low priority P4. Immediate resolution means that a defect causes the system to be almost impossible to use or the test cannot continue. Need to be repaired immediately; a high priority is a serious defect impact test that needs to be prioritized; a normal queue is a defect that needs to be queued for repair, and low priority means that the defect can be corrected when the developer has time.

Correctly assessing and distinguishing the severity and priority of software defects is a major event for testers and developers, as well as for all project team members. This is not only to ensure the smooth test of the requirements, but also to ensure the quality of software is an important link, should be enough attention. Here are three kinds of commonly used technical tools for your reference.

(1) 20/80 principles

Management master Peter Drucker said: "Do things must be prioritized." The worst thing is to do everything, and it will be nothing. And the Italian economist Plato made it more explicit: important minority and trivial majority or the law of 20/80. Is that 80% of the effective work is often done in 20% of the time, and 20% of the work is done in 80% of the time. Therefore, in order to improve the quality of testing, it is necessary to clearly understand which software defects are the most important and which software defects are the most critical. Don't pick up the sesame, but lose the watermelon. Therefore, only by seizing important key defects, the test effect can produce maximum benefit, this is also the first principle---prioritize and use test activities on the most productive things.

(2) ABC law

Ancient cloud: The matter has successively, uses has the urgency. Test work is the case, to distinguish the priorities of software deficiencies, not only to do the processing software defects to order, the effect is also remarkable after the completion. As a result, we need to keep in mind in our testing work that software flaws at hand do not necessarily have the importance of first priority. Only the right judgment can increase the efficiency of the test activity several times.

The ABC rule is one of the important tools for setting software defect priority order. The key point of this ABC tool is to decide the priority order according to the importance degree of software defect, and quantify the plan according to the requirement goal. A software defect is regarded as the most important and most valuable flaw in the test, and it is ensured that first Class A software defect is dealt with firstly. Second, B-class software defects, then the C-class software defects, then others, and some of the less critical software defects are not necessary to do.

(3) Four quadrant principle, classification of software defects

In the process of testing software defects, often encounter a multitude of problems, a wide range of situations, some testers will be tested many software defects crushed, some people are leisurely, efficient completion. What is the cause of this difference? The reason is the classification of software defects is reasonable.

So, how do we classify software defects reasonably? In fact it is very simple, on a coordinate paper, first divided into four quadrants, and then just remember four words on the line, that is, "priorities." "Light" refers to a relatively important but not urgent software flaw; heavy "refers to the most important and urgent software defects;" Slow "refers to software defects that are not important or urgent;" urgent "means not the most important but most urgent software flaw. After clearing this relationship, even if you test many different types of software flaws at the same time, you will quickly understand which software defects must be completed immediately, which can temporarily slow down, so that will not be overwhelmed by the mountain of software defects, testing efficiency will be greatly improved.

Three basic states of software defects:

(1) Activation status (active or open).
(2) Corrected status (fixed or resolved).
(3) A closed or inactive state (close or inactive).

Causes and classification of software defect analysis

There are three main reasons for software defect Analysis: Technical problems, teamwork, software itself. From the test point of view we divide the software defects into five categories: functional defects, system defects, processing defects, data defects, code defects.

Four, software test psychology problem

(1) The process of program testing is destructive.
(2) Programmers should avoid testing their own programs.
(3) The programming organization should not test its own program.