Test plan・Sharing of tests (Part 2) Primary isolation and debugging of defects　

23/04/202120/10/2021Test qualityy

Test reader or design / implementation leader for temporary isolation of defects

In the previous article, we introduced the design, implementation, recording, and reproduction of the divisions written in the software test plan, but in this article, we will continue to introduce the divisions of primary isolation, debugging, and final confirmation .

The bug detected in the test may be a software bug, but it may not be a bug, so it is necessary to temporarily isolate the bug first . Temporary isolation is a classification of defects due to the following general causes.

1. Incorrect source code　(clear software bug where the software is not working in the design document)
2. Incorrect　design document (software bug that software does not meet the required specifications due to an incorrect design document)
3. Wrong test procedure ( wrong test procedure written in the test procedure manual)
4. Judgment condition error　( wrong judgment condition written in the test procedure manual)
5. Inadequate test environment　(There was a problem with the test environment and the test result was incorrect)
6. Test execution error (The test was not performed according to the test procedure manual)

Since 1 and 2 are soft bugs , it is necessary to have the coder and designer debug the software, respectively, and it is necessary to inform the design / implementation team of the bug. Since 3 and 4 have no problem with the software and are mistakes in the test design, it is necessary to inform the test designers in the test team to correct the test design . Since 5 is a problem of the test environment such as an error in the test equipment and data for the test, it is necessary to inform the person in charge of preparing the test environment in the test team and have the environment corrected . 6 is a retest by telling the person in charge of the test .

Temporary isolation affects the efficiency of testing and debugging because it determines who will do what next for the defect . In many cases , the leader of the test team is in charge because it requires knowledge and some experience about the software to be tested and the entire test in order to perform temporary isolation correctly, but in some cases design and design. The implementation team leader may also be in charge. In any case, clearly state in the plan the division of temporary division and the timing of implementation.

For soft bugs, the design and implementation team is in charge of debugging

If the bug is a soft bug such as an implementation error or a design error, it is the person in charge of the design / implementation team who will perform the debugging work . On the other hand, if the defect is a test design error or a test environment problem , the person in charge of the test team will handle it. Since it is clear that the division of these correction work will be one team with the actual person in charge, it is often not necessary to bother to write it in the test plan.

However, in the case of large-scale software development, if the design / implementation team is divided into a team in charge of designing / implementing the first version and a team that fixes bugs found by the test team , etc. In some cases, it may be better to specify which sub-team in the design / implementation team is responsible for debugging.

It is the responsibility of the implementer to check the correction effect, but the tester may help.

Debugging individual software bugs 　proceeds in three stages: ( 1 ) investigation of the cause, (　2 ) correction of the source code, and (　3 ) confirmation of the correction effect . In many cases, the person in charge of implementation is in charge of (1) to (3), but when the number of bugs is large and the person in charge of implementation is insufficient , the person in charge of testing may help with the work of (3 ). This is a sharing method when you want to improve debugging efficiency as much as possible by having the person in charge of implementation concentrate on the work of (1) and (2).

From the viewpoint of work efficiency, it is better for the implementer who knows the contents of debugging best to be in charge of (1) to (3), but when there are many bugs and the release time is approaching, etc. If you want to prioritize shortening the debugging time over work efficiency, the test team may share ③.

Since such a situation depends on the situation of the software development project, it is difficult to decide what to do in the test planning stage, but ③ If there is a case where the test team shares it, such a possibility It is better to write in the test plan that there is.

Who on the design / implementation team will register the debugged source code?

After confirming the effect of debugging, the next step is to register the debugged source code in the master tree . Of course, this is shared by the design / implementation team, but if the person in charge of implementation registers himself / herself in the master tree, there is a person in charge who specializes in the operation of the master tree , and that person goes to the master tree. You may also be required to register.

It is common for the person in charge of implementation to register in the master tree, but if software development is large and the impact of incorrect registration in the master tree is large, a person in charge who specializes in operating the master tree will be assigned. By doing so, we may take a system to reduce the risk of incorrect registration in the master tree due to operation mistakes or illegal procedures . In any case, registering the source code in the master tree is an important task, so it is good to write the division in the test plan.

The final confirmation of the completion of the correction is the responsibility of the test team

When the debug result is registered in the master tree and a modified version of the software (execution image software) is generated from the master tree, a test is performed to confirm that the defect has been fixed . This is a confirmation that the correct test result will be obtained in the future by re-doing the same test item that found the defect first, so naturally the test team will share it.