How is the test cycle compressed in case of an emergency?

Test cycles are compressed in emergencies this is the case for most companies in the country, so how do you face and start testing?

　

First we need to figure out what is causing the situation to happen. Whether internal causes or external causes, in the final analysis if the external causes are basically due to changes in demand , internal causes are usually caused by development delays.

In the following I will enumerate the common processing methods:

1, if the test cycle caused by the demand change is compressed, we must first Test with the project manager, Test Manager to explain the situation and get a unified awareness, and communicate with customers for a longer software cycle.

2, if the test period caused by internal causes is compressed, then we can be processed by the following methods:

①, to the leadership of the current situation, the need to increase the testing staff ( to ensure that people come in to improve progress, rather than slow progress, bring more problems, the best heart has some candidates, regardless of the given, the first to say ):

If you have a complete test plan/test scheme, you can speed up the test by adding testers;

If you do not have a complete test plan/scenario, or if you are unable to coordinate additional testers, you can consider coordinating the developer engagement and cross-testing the module;

②, re-establish test strategy:

In fact, in the actual situation, many company teams will encounter the test cycle is compressed and can not be increased/coordinated to the relevant personnel to participate in the test situation. That's when we have to readjust our testing strategy.

First, we need to explain the situation to the project manager and coordinate the change test scope (priority to ensure the basic functions, common functions and important functions of testing);

Second, with the project leader, QA to say hello, minimize the official document recommended the use of test results for output;

Re-testing process to give priority to verbal communication, non-important modules of small bugs, do not affect the user's use/not affect the function of the bug recommended first record can not be submitted to the bug management system, first timely processing;

There are also arrangements for testing the need to optimize the testing staff arrangements, as far as possible to allow experienced, strong ability to test complex modules, the ability of ordinary people to do simple modules;

Finally, we can communicate with the development, confirm the risk of the local key test and so on.

risk management must be strengthened when the ③ and test cycles are compressed

The risk of the compression test cycle should be timely collated, fully considered and actively reported and quickly follow-up, do not find the risk after ignoring.

　　　

How is the test cycle compressed in case of an emergency?