Test plan・Sharing of tests (Part 1) Design, implementation, recording and reproduction
- 1. Write the division of test work concretely in the software test plan
- 2. (1) Test design is in charge of the test team
- 3. (2) The test team is also in charge of conducting the test
- 4. (3) Clarify the items to be recorded when recording defects.
- 5. (4) Decide who will be in charge of reproducing the defect.
- 6. If it can be reproduced, it is a bug or not.
Write the division of test work concretely in the software test plan
After writing the goal in the software test plan, next I will write about the division of test work . Software testing and debugging are carried out in collaboration with the design / implementation team and the test team. Basically, the test team finds a defect in the test, and if the defect is a software bug, the design / implementation team will be in charge of debugging , but some work can be done by either team. I have.
As the test progresses, multiple defects are found, so the test team and the design / implementation team must deal with multiple defects at the same time . Therefore, if you do not decide how to divide the test work and how to cooperate and write it in the test plan , confusion will occur.
More specifically, in the break down of the test and debugging work, since in the following manner, these whether carried out by each of which team the work of Toka, between the design and implementation team and the test team, how to share information and Te coordination of work is either to the, decided at the stage of systems, including test design used, it is good idea to write the test plan.
- Test design (embody test items, test environment, and test procedures)
- Conducting the test (actually conducting the test according to the contents of the test design)
- Defect record ( record the content of the defect found in the test and the conditions under which it occurred)
- Reproduction of defects (check the reproduction status of defects found in the test)
- Isolate bugs (determine if the bug is a software bug)
- Bug fixes (Investigate the cause of the bug and fix the source code)
- Confirmation of correction effect ( confirm that the bug has been fixed with the corrected software)
- Registration of correction contents (Reflect the modified source code in the master tree)
- Confirmation of completion of correction ( confirm that the bug has been removed from the master tree)
Let’s take a closer look at each task.
(1) Test design is in charge of the test team
In test design, (1) decide the type of test to be performed, (2) decide each test item , (3) select the environment and equipment necessary for the test for each of those test items , and (4) write down the specific test procedure . ⑤ We will proceed with the work of deciding how to judge the test results .
This test design is done by a person in charge of test design who has a lot of test experience in the test team . When the scale of the test is large, multiple test designers may share the test design for each type of test, and the test design results may be mutually designed and reviewed, so who is which test? It is good to write in the test plan even the division of designing.
(2) The test team is also in charge of conducting the test
According to the test procedures that have been created, the ring of the test collect the border and equipment actual and proceed with the test work is given, the test team test the person in charge is the work of. In the case of software testing, you cannot perform test work unless you know how to set up and use the test environment and test equipment .
In order to proceed with the test efficiently, it is necessary to decide the division of the tester , including whether the test environment and test equipment have been used . If the tester is new to the environment and equipment, it is a good idea to include time in the test plan to get used to those operations.
(3) Clarify the items to be recorded when recording defects.
The test staff of the test team records the defects found in the test, but (1) where to record the information about the defects, (2) what kind of content is written to record the defects, and (3) how detailed each item is. Decide whether to write it before the test and write it concretely in the test plan. In general, I think it would be good if the following items were written in the plan.
- Defect recording destination (EXCEL table or bug tracking system)
- Defect detection date and discoverer (when and who found it)
- Test items that detected defects (in which test the defect was found)
- Details of the defect (Which part of the test result was incorrect)
- Confirmation of defect (specifically, screen display, log, etc. indicating that it is incorrect)
- Defect occurrence conditions (environment, device settings, etc. when a defect is detected)
(4) Decide who will be in charge of reproducing the defect.
When a defect is found in the test, the investigation of the defect starts, but the important thing in the investigation is whether the defect can be reproduced . This bug of reproduction is any team in charge and what the timing or to implement in is various by development organizations and roles of testing and debugging.
In many cases, the person in charge of testing is responsible for reproducing the defect, but in some cases it may not be the case. Depending on the situation of the software development project at that time, for example, one of the following may occur. Regardless of the division, it is good to clearly determine the division of reproduction work at the beginning of the test plan and write it in the test plan.
- The person in charge of the test who found the defect (this is the case if the efficiency of reproduction is important)
- Reproduction staff in the test team (when the accuracy of recording such as reproduction conditions is important)
- Person in charge of design / implementation team (selection when you want to reduce the load on the test team)
If it can be reproduced, it is a bug or not.
If the bug found in the test is caused by a software bug, debugging work is required, but for that purpose it is necessary to isolate whether it is a bug or not. I will introduce the isolation of defects and the subsequent work in the second article.