Overview・Items to write in the software test plan

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

Planning and management is important for software testing

It is not limited to software testing, but when you start something, you confirm the purpose , decide the policy and goal to achieve that goal, make a plan to reach that goal, and make progress of the plan It is important to manage it . Unlike hardware, software is invisible and difficult to manage, but software testing is even more invisible, so if you don’t manage it carefully, it won’t work. The first step in management is planning, so let’s start with a test plan .

What is a test plan? Goals, systems, responsibilities, environment, and tracking

The test plan is written in the test plan, but what items do you write when creating the test plan? Even though it is a test plan, the general format is not fixed, so you can write it in any way, but when you review the test plan, Father Gutara writes the following items properly. I was careful if it was issued.

• Is the test policy and goals written in an easy-to-understand manner?
• Is the division and system of tests clear?
• Is there a specific way to manage the test ?
• Is there a description of the test environment and its preparation ?
• Is it clear how to track the problems found in the test ?

In the test plan, write the test policy at the beginning

The purpose of the software test is either to guarantee the quality of the software (confirm that there are no bugs) or to improve the quality of the software (detection of bugs), so this does not need to be rewritten. Therefore, the first thing to write in the test plan is the test policy for this test work .

The test policy is the item that is emphasized in conducting the test . For example, if you are testing newly developed software, you will focus on the comprehensiveness of checking functions and performance, and if you are testing a bug-fixed version of software, you will focus on checking the effect of the fix and checking for secondary defects . If you are testing software where it is important to keep the development release date, you will focus on observing the test schedule . Depending on the purpose of releasing the software to be released, the test policy of what to focus on testing the software changes, so it is good to write the test policy at the beginning of the test plan .

Write test goals as quantitatively as possible

Once the test policy is decided, the next step is to write down the goals for this test . The goal of software testing, progress management of the target Toka goal of bug detection Toka, target of bug fixes Toka, There are many in the vertical way of the goal. Among them, if you set one or two goals according to the policy of this test work, one more goal, and two or three goals in total, you can look back after the test. useful.

The goals set here will be easier to manage if you consider the quantification method as much as possible and make it possible to set goals and check the achievement status by quantification. If you aim for test progress, you can quantify it by the milestone achievement rate (the ratio of the number of milestones that can be achieved by the planned date), or if you aim for the amount of bugs detected, the bug detection rate for the amount of newly developed code You can quantify something with, or by devising a little for each goal.

The division and structure of the test should be decided before the start of the test.

The software development work when the software is being tested is written out mainly for the test, roughly as follows.

1. Test design (embody test items, test environment, and test procedures)
2. Conducting the test (actually conducting the test according to the contents of the test design)
3. Defect record ( record the content of the defect found in the test and the conditions under which it occurred)
4. Reproduction of defects (check the reproduction status of defects found in the test)
5. Isolate bugs (determine if the bug is a software bug)
6. Bug fixes (Investigate the cause of the bug and fix the source code)
7. Confirmation of correction effect ( confirm that the bug has been fixed with the corrected software)
8. Registration of correction contents (Reflect the modified source code in the master tree)
9. Confirmation of completion of correction ( confirm that the bug has been removed from the master tree)

Which of these tasks will be handled by the test team or tester and which will be handled by the design team or coding person must be shared and written in the test plan before the start of the test . I think that 1 to 3 are often carried out by the test team and the test staff, and 5 to 7 are often carried out by the design team and the coding staff. However, regarding 4, 5 and 8, it often changes depending on the situation of the project, whether the test team or the design team is in charge, so check it first and write it in the plan.

At the same time, decide how to share each work within the test team, and in some cases , divide the test team into several sub-teams (reproduction staff, correction completion staff, etc.) and establish a test system . Making it is also necessary for large-scale software development . Consider this as a test plan and write it down in your plan.

Test management clarifies how to plan and collect performance and modify plans

Software testing work proceeds with design, implementation, and use of results (bug recording and tracking). The schedule of these tasks, equipment and personnel plans should be written out in the test plan.

Then, after the actual test design and test implementation are started according to the test plan, it is necessary to monitor whether the test is proceeding according to the plan and manage the test so that any deviation from the plan is corrected. there is.

Monitor the progress of the test based on the test deliverables such as the number of test items designed at the test design stage and the number of test items completed at the test execution stage, and the number of bugs found. There are various monitoring methods, such as monitoring the effectiveness of tests based on test artifacts such as the number of bugs fixed.

No matter which monitoring method you use, you will not be able to collect the necessary information unless you first decide what kind of information to collect . Therefore, in the test plan, it is necessary to specifically describe what to do as test management and what kind of information to collect for that purpose .

At the same time, it is better to write what to do if a deviation from the test plan is found as a result of monitoring . It would be nice if the deviation from the plan could be recovered within the test team, but if recovery is not possible within the test team alone, escalate the problem to the upper organization as soon as possible and coordinate with the overall software development plan. It is also necessary to proceed with. It would be good if the test plan also describes how much deviation from the plan should occur and what method and route should be used to escalate the problem.