Test plan・Priority and track bugs and bugs
It is important to set priorities when managing bugs and bugs
As the number of bugs and bugs found in software tests increases, it becomes important to prioritize responses and track the progress of responses . It would be nice if all the bugs and bugs could be dealt with until the next release, but the reality is that the number of bugs and bugs is not so large. In that case, it is necessary to manage the response by priority so that the most important defects and bugs can be dealt with first, so the priority allocation of defects and bugs is required. is important to and track according to the priority. increase.
Continuing from the previous article, this article introduces 6 and 7 of the following 7 items necessary for managing bugs and bugs.
- Classification of defects (how to classify defects such as bugs, test setting mistakes, test implementation mistakes, and environmental deficiencies)
- Defect record (In defect record, write the defect reproduction method and management information without omission)
- How to record a defect (whether to enter it in some system or write it in an EXCEL table)
- State definition (what state each defect or bug transitions to and finally ends in the final state)
- Termination judgment (who decides by what criteria the defect has been dealt with)
- Prioritization (who and how to prioritize bug and bug investigations and countermeasures)
- Tracking (who monitors the state transitions of individual defects and how to take measures against delays)
6. Prioritize bugs and bugs
There are also several ways to prioritize the handling of bugs and bugs. It is better to use the method that is suitable for each software development project, not which is the correct answer, but how to set the priority should be clarified in the test plan. Here are some examples for your reference.
(1) Prioritize based on importance
Prioritizing responses according to the importance of defects and bugs is a fairly straightforward idea. There are various definitions of the importance of bugs and bugs, but in this article, we will say how important the user is when the bug or bug occurs . It’s a little rough, but if you write the importance a little more concretely, for example, using a home HDD recorder as an example, it will be as follows.
High importance : No equipment or functions can be used, HDD recorder does not start even when the power is turned on
Medium importance : Main functions cannot be used, HDD recorders cannot record new programs, etc.
Low importance : Auxiliary functions cannot be used, and if it is an HDD recorder, the edges of the recording list screen will be cut off and cannot be seen.
From the perspective of advancing software debugging, if there is a bug of high importance, the test will not start in the first place, so it is necessary to take immediate measures, and if there is a bug of medium importance as in the example Since it is not possible to test the playback function of recorded programs, it is necessary to take measures urgently. In this way, giving high priority to items with high importance of defects and bugs is a relatively easy-to-understand idea.
(2) Prioritize based on the likelihood of problems
Some problems occur due to defects and bugs, but there is also the idea of giving priority to problems that are likely to occur . The idea is to get rid of problems that occur immediately, rather than problems that rarely occur under special conditions. Here, too, using an HDD recorder as an example, the susceptibility to problems is specifically described as follows.
It always happens : It always happens when you use it normally, and it happens when you operate the recording with an HDD recorder.
Occasionally happens : It happens when some conditions are met, and if it is an HDD recorder, it happens when you reserve a recording at 22:00 on Tuesday on Sunday.
Rarely happens : It happens when some conditions and probabilities are met. With an HDD recorder, if you make a recording reservation at 22:00 on Tuesday, it happens about once in 200 times.
If you release the software with problems that always occur, the call center phone will not stop ringing, so you need to give top priority to the problem, so it is understandable that the more likely the problem is to be dealt with first. How to prioritize.
(3) Prioritize based on the degree of impact on you service
Also occur ease importance because both also important, that you consider to suit both of that is, the degree of influence on the user service is the idea. Simply put, the importance is maximum is likely to issue impact occurred at large , the importance of the problem degree of influence that rarely occur in small is the lowest thing that think that.
In order to rank things with intermediate importance and likelihood, 3/2/1 is assigned in the order of importance, medium / small, and the likelihood always occurs 3. Occasionally 2 and rarely 1 and a value to multiply the importance and likelihood The idea is to assign a value from the one with the largest value obtained of .
It takes a little time to decide the two values of importance and susceptibility for each bug or bug, but if there are many bugs or bugs, this user service will be used. If you prioritize based on the degree of influence, the priority will be highly convincing.
(4) Add importance to software release depending on whether or not measures are taken
The direction of thinking is a little different from the above three, but the results of dealing with defects and bugs will be effective only when they are incorporated into the software to be released next and provided to the market . Therefore, it is very important whether the countermeasures can be completed by the timing of the next software release.
When dealing with bugs and bugs, it is important to maximize the effect using limited time, people and equipment , so there is also the idea of focusing on bugs and bugs in time for the next release and proceeding with countermeasures. Therefore, it is this method to prioritize bugs and bugs that will be fixed in the next software release, and lower the priority for those that will be sent to later releases.
7. Bug and bug tracking (progress management)
After assigning priorities to bugs and bugs, it is also necessary to decide how to track high-priority bugs and bugs to see if countermeasures are being taken at the test planning stage. Tracking is the closest term to progress management in Japanese, but when working with overseas development bases, it is often called Tracking, so Gutara’s father calls progress management for defects and bugs even in Japan. I used to call it Traking. There are three things to keep in mind when creating a test plan for this tracking.
(1) an update of the management database of the condition and the bug
When a defect or bug is detected, it is registered in the tracking system or EXCEL table, which is a management database . After that, the actual debugging work such as reproduction, investigation and countermeasures will proceed, but the first step of management is to update the contents of the database in synchronization with the progress of the work .
I sound like too obvious that, in the are advancing actually debugging of software scene, the person in charge of the plurality of defects and bugs backlog was imminent suffer from a software release dates are evicted in It often happens that you are in a death march state. At such times, updating the administrative database that does not contribute to the actual bug fix tends to be postponed if you take a little care .
If the update of the management database is delayed, it will not be possible to see the current status of how many bugs have been fixed, so be sure to update the management database at the end of daily work so that such a situation does not occur. It is also important to take measures such as establishing work rules such as doing.
(2) Confirmation of the number of remaining cases by priority and state transition
When checking the response status of defects and bugs numerically, it is easier to understand the status by looking at the remaining number in the matrix table created by priority and state transition . It depends on the scale of the software development project, but if you look at the number of remaining cases in this matrix table about once a week, it seems that the progress of debugging and how many bugs will be fixed by the time of release. You can make some predictions. In your test plan, decide specifically what format and how often you want to manage the remaining defects and bugs.
(3) Review the priority when the release time is approaching
Bugs and bugs are dealt with with priority, but it is recommended to incorporate in the test plan to review the priority of the remaining cases once when the release time approaches . .. The weeks before the release are important periods that affect the quality of the software. Correct priority management is required to make effective use of this period, so be sure to include the timing of prioritization review in your test plan.
If you have plenty of debugging power and the number of remaining bugs is small, you may be able to raise the priority of bugs and bugs that were postponed to the next release and incorporate them into this release. On the other hand, if the debugging ability is insufficient and there are many remaining bugs, some of the high-priority bugs and bugs will be postponed, and the floating personnel will be given the highest priority to support the bugs and bugs. It may be better to assign it to.
We don’t review our priorities often, but when the release time approaches, we 'll do it at least once so that we have the opportunity to reconfirm whether we can keep the current priorities and run to the end. We recommend that you have a good test plan.