Test plan・Definition of bugs and bug states is important for managing bugs and

31/05/202121/10/2021Test qualityy

It is necessary to define the status (status) to manage the response status of defects and bugs.

It is most important to investigate the cause of any defects or bugs found in the software test and proceed with countermeasures . In order to manage the progress of countermeasures, it is necessary to define a state (status) that indicates the step of the work from discovery to completion of countermeasures for defects and bugs . Determine the definition of the state, and based on that state, (1) what state the defect or bug is in now, (2) who is in charge of what work at this point, can clearly understand the defect or bug. mechanism of management it is important to keep thinking only at the time of the test plan.

In the previous article, I introduced the contents of 1 to 3 out of 7 items that are not necessary for managing bugs and bugs, so this article will introduce items 4 and 5.

1. Classification of defects (how to classify defects such as bugs, test setting mistakes, test implementation mistakes, and environmental deficiencies)
2. Defect record (In defect record, write the defect reproduction method and management information without omission)
3. How to record a defect (whether to enter it in some system or write it in an EXCEL table)
4. State definition (what state each defect or bug transitions to and finally ends in the final state)
5. Termination judgment (who decides by what criteria the defect has been dealt with)
6. Prioritization (who and how to prioritize bug and bug investigations and countermeasures)
7. Tracking (who monitors the state transitions of individual defects and how to take measures against delays)

4 . Definition example of bug or bug state ( example of bug or bug state transition)

There are various definitions of the state (status) of a defect or bug, and one example is to define the states (1) to (9) as shown below. In this example, the status is defined based on the debugging procedure for software bugs caused by software design and implementation .

In this example, for problems that are caused by the test team, such as test design and test environment, other than software bugs, it is necessary to read and use the definition of the state for software bugs . However, if the development scale is large and the number of problems caused by the test design or test environment is large, it may be easier to manage by deciding another definition, so what kind of definition should be used? Whether it is good or not depends on the project.

Let’s take a closer look at each status in this example.

(1) Not started

This is the initial state when a defect or bug is found in the test and the content is registered in the defect management system or EXCEL table . We haven’t been assigned a person to try to reproduce it yet, so we haven’t started investigating this matter .

(2) Waiting for reproduction work

A person in charge of trying to reproduce a defect or bug has been assigned, but the person in charge is doing other work, so the reproduction work of this case has not started yet .

(3) Reproduction work in progress

The person in charge of reproducing the defect or bug is working on the reproduction, but the result of the trial has not been obtained yet . (If multiple trials are required for reproduction, or if long-term operation is required, the state of reproduction will continue for a long time)

(4) Waiting for cause investigation

The reproduction method was found, and a software engineer in charge of investigating the mechanism (cause) of the occurrence of defects and bugs was assigned, but since the person in charge is doing other work, the investigation work of this case has not started yet. There is no state.

(5) Under investigation of cause

The person in charge of investigating defects and bugs is investigating the mechanism and cause of the occurrence of the defect, but the cause has not yet been clarified . (A simple bug may take hours to find the cause, but a difficult bug may take days or months to find the cause.)

(6) Code is being modified (debugging is in progress)

Now that we know the mechanism and cause of the bug or bug, we are in the process of conducting a series of debugging work to examine the correction method , correct the source code according to the contents , and check the correction effect . (A bug that is complex and has many changes may require a period of days to weeks.)

(7) Waiting for retest

When the design / implementation team finishes reflecting the modified source code in the master tree , the next work will be taken over by the test team. The software of the execution image generated from the master tree that reflects the correction is passed to the test team , the test item that detected the defect or bug is executed again, and the test result that the defect or bug is fixed is displayed. I’m waiting for you.

(8) Completion of individual measures

This is the state in which the work to deal with the bug or bug in the version of the software in which the bug or bug was detected has been completed . After this, we will move on to consider whether it is necessary to deploy other versions (older versions) or modifications to the master tree of another product that uses the base code from which it was developed, if necessary. To do.

(8) Horizontally expanding to other master trees

We are waiting for a reply that we have received the information of this bug or bug as a potential bug in the master tree of another version or another product that uses the same base code . .. Whether or not to make corrections based on the horizontally expanded information is decided by the project of another version or another product, so as a countermeasure for this defect or bug, if it is confirmed that the information has been transmitted, it will end there. ..

(9) Completion of all measures

All the bugs and bugs found , including confirmation of horizontal expansion of information to other versions and other products, have been completed .