Defect tracking management is an important part of the test work. The purpose of the test is to discover defects in the software system as soon as possible, and therefore, the defects are tracked, ensuring that each discovered defect can be dealt with a test work. important content.
1. Target for defect tracking management
Defects can cause an undesirable or unacceptable external behavior resulting in software runtime, and the software testing process is simply to be carried out around the defect, and the tracking management of defects is generally required to achieve the following goals:
Make sure that each of the discovered defects can be resolved; what is solved here is not necessarily corrected, or it may be other processing methods (for example, correcting or correcting in the next version), in short, for each discovery BUG's processing must be able to achieve consistency in development organizations;
The defect data is collected and the phase of the test process is identified according to the defect trend curve; if there are many ways to determine whether the test process ends, it is common and more effective in determining whether the test process is ended by the defect trend curve.
The defect data is collected and the data analysis is performed as the process of the organization.
The first one of the above is the most important point. When it comes to defect tracking management, it will immediately think of this, but it is easy to ignore the second and third objectives. In fact, in a well-running organization, the collection and analysis of defect data is important, and many data related to software quality can be obtained from defect data.
2, description of defects
The description of the defect should contain the following content:
The unique defect ID of the information defect ID can be tracked, which can be "to be allocated", "to be corrected", "to be corrected", "to be corrected", "to be corrected", "to be corrected", "to be corrected", "to be corrected", "to be corrected", "to be corrected", "to be corrected", "to be corrected", "to be corrected", "to be revised" Defect header describes the severity of the title defect of defects describes the severity of defects, generally divided into "deadly", "serious", "general", "recommended" four defects, the emergency description, from 1-4 1 is the highest priority level, 4 is the priority minimum level defect author's defect author's name (mail address) defect submission time defect submissions to the time defect belongs to the item / module defects belongs to the items and modules of the defects, etc. More accurately positioned to module defects designation to solve the resolve of human defects, "Submit" is empty in the defect "submission" state, designated by the project manager by the project manager by the project manager, designated developers designated by the project manager in the defect "distribution" state Modify the defective defect processing result of the defect defect processing person of this defect defect, the description of the processing result, if the code is modified, the time defect verifier of the modification defect time defect processing is required here. The verification person defect verification result describes the description of the verification result (by, not passing) the detailed description of the time defects of the defect verification; the reason is to list this separately, because The detailed extent of the defect description directly affects the modification of the developer's defect. Describe the description of the environment should be tested as much as possible to the description of the test environment. It is difficult to express clearly defects for some text, using pictures and other accessories are necessary defects The description item is described in the lavender that is described in the defect in the processing phase; the defects are described in the verification phase in the verification phase. In addition to the above description, items such as "defect introduction phase", "defect correction workload" can be added from the perspective of the statistics.
3, general flow of defect management
The process of defect management is relatively simple, Figure 1 is a schematic diagram.
Role in the process:
1. Tester: The person who tested the test, the initiator of the defects;
2. Project Manager: Responsible for the entire project, responsible for product quality;
3. Developers: Executive development tasks, complete practical design and encoding work; 4. Review Committee: The defect is finally confirmed, and the project member will be arbitrated when the defect is not consensus.
Defective state
1. Initialization: The initial state of defects;
2, to be allocated: defects waiting to be assigned to related developers;
3, to be corrected: defect waiting for developer amendment;
4, to be verified: developers have completed corrections, waiting for testers to verify;
5, to be review: Developers refuse to modify defects and require review of reviews;
6. Close: Defect has been processed.
4, defective data statistics
As mentioned earlier, defective data statistics are also the goal of defect tracking management systems. In general, the generated defective data statistics chart includes defect trend graphs, defect distribution maps, defects, timely processing statistics, etc.
5, defect tracking management system
At present, existing defect tracking management software includes Compware's TrackRecord software (commercial software), Mozilla's Buzilla software (free software), as well as domestic minimally invasive BMS software, these software is functional, can be based The actual situation is selected. Of course, you can also develop defect tracing software, such as Notes or ClearQuese development defect tracking management software. Our company uses its own Notes-based defect tracking system, in addition to having the above functions, it is also possible to easily send a reminder information (defect processing timeout reminder, defect processing reminder, etc.) through NOTES's mail system.
In addition, as a defect tracking management system, you must pay attention to the issue of authority allocation. Defect records as important data in software development, cannot be deleted easily; for defects that have been closed, they cannot be modified. Therefore, the defect tracking management system must set strict management rights, and non-related personnel must not perform the corresponding operation, modify the corresponding data. At this point, it is also easy to control through Notes.
