About test scheduling


Recently, a test friend encountered a problem about test scheduling and briefly talked about his ideas.


The organizational structure is like this. Project development and products belong to the same department, and testing belongs to the same department with their own leaders.

Due to the poor development quality, such as the simple function of displaying data from the database to the page, 40 + bugs can be found in three or four pages, and 6 + bugs can be reactivated, so the test and evaluation period is relatively long.

As a result, the project leader called back the evaluation date of the test twice and asked them to reschedule. The test students actually felt the meaning of the project leader, but did not take the initiative to communicate with the project leader and their own leaders.

Results today, the test students interviewed their leaders and found that the project leader had complained with their leaders for many times, so the test students explained the reasons, and the leaders realized it and told the test students the solution.

First, take the number of bugs and reactivations of each iteration and have a gentle talk with the project leader, so that the project leader can properly control and improve the quality next time. If not, it may have to be called back.

If the iteration period is not long enough, we can estimate the quality of the whole project by three points. If the iteration period is not long enough, we can improve it directly. In this way, we can estimate the quality of the whole project by three points. In case the delivery period is not long enough, we can improve it by three points.

Personal suggestions:
In the process of testing and estimation, the general principle is to follow: the testing time is about 1 / 3 of the development time, and not more than 1 at most (except for special circumstances of course).
The length of the test schedule depends on the efficiency of the test students, the complexity of the business, the test quality and the speed of developing students to repair bugs, etc.

In the actual evaluation process, the evaluation period shall be based on the normal project quality and human cooperation. If there are problems such as poor measurement quality as mentioned above, it shall be fed back during the implementation process to let everyone see the problems. Even if the follow-up project is delayed, the project leader can accept it.

However, if the test students evaluate various risk factors, such as poor quality, in their own test time at the beginning, it is unfavorable to the individual and the whole test team, because the project leader will ignore the quality problem most of the time when looking at the construction period, and only consider it from the business complexity and test efficiency. If it is a very simple function, due to the long evaluation period of quality problems, Project leaders generally question the test efficiency first.

This is a problem involving the interests of the Department. It is necessary to take the data and give feedback in time.
Therefore, the above solutions: first take the data to talk to the relevant person in charge about the quality problems, then the normal evaluation period, and use three iterations to verify whether it is feasible. It is a good solution.

PS: I’m LC xinxinzi. The name of the whole network is unified. I look forward to your attention~
Original article, reprint please indicate the source~