Incorporate Requirement Changes without Loosing the Testing Focus

Case: In a project the client says that there will be frequent changes in the requirement for the next 3 months. The development in X build can be changed in X+1. So there is no point of testing the product for next 3 months, till the product is stable. So I would like to scrap the testing team till that point of time.

Now, how would you convince your client that the testing team should be retained?
Your argument:

1. By definition, testing is a continuous process and must go hand-in-hand with the development. Testing team is expected to respond to the changes in the same fashion as development team does.

This will also save time for the testing team as the adaptation time at the end of 3 months would be higher than now.

2. If the testing team is scrapped now, it would be difficult to build similar team in the future. The current team has good product/ domain knowledge and has good experience of working on the product. We will incur cost to train new testers in the team.

3. Test scripts (Automation or Manual) should be changed based on the change in the requirement. Also, testing team should able to identify the affected modules from the changes in requirement. This will lead them to effective regression testing.

4. Convert Systems Testers to Unit testing and Integration testing team to expedite the development. This will also prevent any crashes or major defects to be detected down the cycle. Backtracking to one of the previous release would cost higher in such a case.

5. Change the development methodology to Agile. Agile incorporates all the changes at the run time and very effectively. At the end of each cycle (15 or 30 days sprints in Agile), these implemented changes needs to be tested. Because as per the Agile development methodology, we get the potentially shippable product after each sprint.

Consider keeping this process ongoing. Because, you can’t be sure that customer would not change the requirement frequently in future too.

6. Last but not the least; negotiate for reducing the number of testers rather than scrapping, using one or combination of arguments mentioned above.

As a whole, testing efforts should be proactive and not reactive to the changes. Howsoever big the change could be -- testing can adapt itself without loosing the track, with total control and process.