Test report・Write an evaluation of the test schedule in the evaluation of the test plan

02/08/202121/10/2021Test qualityy

In the test evaluation, write the evaluation about the test schedule following the test content.

Write the test result and test evaluation in the software test report. The status of the bug detected in the test is the test result, and the good or bad of the test plan and implementation is the test evaluation . Since the evaluation of the first test content of the test evaluation was introduced in the previous article, let’s introduce the evaluation of the second test schedule of the test evaluation a little more concretely in this article .

The evaluation of the schedule is divided into the final result of whether the end schedule of the test was kept and the schedule management in the middle.

The most important result of the test is the status of bug detection , but the second most important thing is whether or not the schedule was met . The evaluation of the schedule in the test report focuses on the final result of the schedule management as to whether the final test end schedule was met, and the evaluation focusing on the state of the schedule management in the middle of the test work. We will evaluate from the two aspects of.

Since the test is the work in the final stage of software development, the release time does not change even though the process delay in the previous process such as design and implementation is carried over, and it is involved in the project where death march has started. Is also common. Since we will be testing in various difficult situations, we will evaluate whether we were able to finish the test by observing the end schedule of the test that we originally planned, and finally we will evaluate the final result and keep the end schedule. We will evaluate from the point of view whether the schedule management was successful in the middle of the test for .

Compare plans and achievements for both start and end dates to see if you kept the end schedule

When evaluating whether or not the test end date has been met, not only the test end date but also the plan and actual results are compared and evaluated from the following three perspectives.

1. Evaluation of test end date: Is the actual test end date deviated from the plan?
2. Evaluation of test start date: Is the actual test start date deviated from the plan?
3. Status of rescheduling : Was there any revision of the test plan to change the start date and end date of the test?

(1) Evaluation of test end date

The test end date evaluation evaluates whether the actual test was completed by the test end date described in the latest test plan . The evaluation is good if the test is completed according to the planned schedule, but if the schedule is delayed, the actual result of the test start date will also be taken into consideration. If the start of the test starts according to the plan and the end date of the test is delayed, it is not possible to evaluate the end date of the test . However, test later than the start of the plan have that much test end date is delayed as long as, for the test end date variable-evaluation is not an impossible it is. (Evaluation is assumed to be evaluated on a three-point scale of good> acceptable> unacceptable)

(2) Evaluation of test start date

When evaluating the test start date, it is good to simply evaluate by the size of the delay from the planned date . Than the start of the test plan unless the delay of the start date of the evaluation is good at, delay was out the number of days that delay is written to the plan in the case evaluation if within 10% of the overall schedule is variable and, 10 If there is a delay of the start date that exceeds%, evaluation is not possible . In addition, it is easy to understand that the evaluation of the end date and the evaluation of the start date are evaluated by comparing the latest plan schedule with the actual schedule. Regarding the plan change from the schedule of the first edition plan, we will evaluate it in the situation of reviewing the next day.

(3) Status of schedule review

Ideally, the test plan can be used to the end as it is in the first edition, but in reality, the plan may be reviewed due to various factors . When there is a change in the test start date or test end date, it is very important to properly review the schedule and revise the plan in order to manage the test successfully. After the test was completed, if there was a difference of 10% or more between the planned schedule and the actual schedule for the start date and end date of the test , was the schedule properly reviewed? Please look back and think about it.

Test schedule management evaluates monitoring cycles, corrective actions and risk schedules

In addition to the evaluation of the final result of whether or not the test end schedule was met, it is also necessary to evaluate the status of schedule management during the test work . Test dates of whether the is progressing as planned monitoring and planning in order to eliminate the deviation in the case of deviation came out from the take countermeasures , but still so if the deviation is larger review of the plan to the, that Yo schedule management is whether the evaluation was not functioning properly. Regarding the status of schedule management, it will be easier to write a test report if you write the evaluation in the following three categories.

1. Maintenance of management cycle : Is the management cycle functioning by monitoring the presence or absence of schedule deviations and taking measures to correct the deviations?
2. Effect of recovery measures　　: Was the effect achieved by taking measures to recover the deviation when the schedule was shifted?
3. Effect of risk schedule　: Was the margin schedule that was incorporated as one of the measures when the schedule was out of sync appropriate?

(1) Maintenance of management cycle

I think that the test schedule management cycle is short, one day long, and often about one week. Based on the schedule management record, evaluate whether the management cycle of monitoring the progress of the actual schedule against the schedule plan and taking measures if necessary according to the management cycle period determined in the test plan was functioning properly. To do.

First of all, we determined the management cycle that or not been implemented not be removed but is the status of implementation of the management, which is planned schedule management number of times and dates management record is counted from the number of implemented the schedule management from, management Calculate the execution rate of the cycle . For example, if the management cycle is once a week and the test period is 24 weeks, the plan is to manage the schedule a total of 23 times . On the other hand, if the actual schedule management record remains 20 times , the implementation rate will be 23% (= 20 * 100/24).

Next, pick up the number of indications that there is a problem with the schedule from the schedule management record . At the same time as picking up the number of issues pointed out, we also check the number of cases regarding whether or not countermeasures have been taken for the problem . The cumulative number of issues / number of management implementations shows the density of indications as to how many problems were found per schedule management , and what percentage of the problems found in the cumulative number of countermeasures implemented / cumulative number of issues was implemented. You can see the countermeasure density .

There is no correct value for either the indication density or the countermeasure density, but from the perspective of whether the implementation status of this test management cycle was appropriate compared to similar tests in the past, the maintenance status of the management cycle. Evaluate the good or bad of.

(2) Effect of recovery measures

Next to the evaluation of the implementation status of the management cycle is the evaluation of whether or not the actual schedule management was effective . There is no good way to measure the effect of schedule management, but one method is to measure the total number of days of schedule fluctuations . The easiest schedule management is in the milestone management to, and the subdividing the work of the design and execution of the test end date of each of the work to the milestone, the deviation from the schedule in the deviation of the actual dates for the plan Date It’s a method of digitizing and managing. If you want to manage your schedule on a milestone basis, make a table of milestone plans and achievements as shown in the sample below.

In this sample, it is currently May 8th, and the actual completion date of the milestone planned by May 7th is entered in the actual date column, and the deviation from the planned date is (whether it is late or early). (Regardless) It is entered in the deviation days column . Based on this management table, when managing the schedule once a week , the number of milestone deviation days scheduled to be completed by that date is accumulated, and the total number of milestone deviation days is tabulated as follows. Will be.

The smaller the total number of blurring days, the more the schedule is proceeding according to the planned schedule . If the management of the progress of the Japan Fine Arts Exhibition works well and is effective, there should be little deviation, so it is an index to evaluate the effectiveness of the schedule management. Of course, there is no absolute standard for how many days or less it should be , so it is necessary to compare it with past tests to judge whether it is good or bad, but it is good or bad if you collect values ​​for some tests. You will be able to make decisions.

(3) Effect of risk schedule

As with all activities , not just tests, no matter how carefully you plan, if you actually execute it, there will be deviations from the plan due to various factors . The same applies to software test schedule management, and no matter how hard you try to manage monitoring and promotion of recovery measures to reduce deviations, you cannot eliminate the deviations . However, if the test is not completed by the planned test end date, the software release date cannot be met and it becomes a big problem as a software development project.

To prevent this from happening, experienced test leaders incorporate risk itineraries into their test scheduling , either explicitly or at first glance . For example, let’s say that the schedule of subdivided work from test design to implementation is 100 days. If 100 days is used as it is for the test schedule, if there is a schedule delay due to some work, it will lead to the test end schedule delay as it is, so there is a high risk in schedule management . To prevent this from happening, if you scatter the schedule around the schedule and sneak in the margin for 5 days, even if something happens for 5 days, it will not affect the test end schedule. This is the risk schedule weaved by the test leader . To put it a little cooler, it’s a risk management technique to keep the test end date.

As for the risk schedule, it may be explicitly incorporated or it may be incorporated in a sloppy manner, so it is difficult to judge whether it is better to include it in a formal test report. A How can, another of the future or good Once you have factored in the risk schedule of how and when to make a test plan because, I do not come out to the surface quite important know-how . Therefore, in the planning stage to the test report if possible I think it’s a good idea to keep a record of the risk schedule that you factored in and the risk schedule that you used in the actual test.