What to Do if Requirements Are Changing Constantly?

August 15 10:00 2011 by Nataliia Vasylyna Print This Article

It is a common situation and a great headache in software testing.

Here are some tips if such situation occurs:

Consecrate appropriate attempt to risk analysis of changes to minimize regression testing needs.
Balance the attempt put into setting up automated testing with the expected attempt required to re-do them to cooperate with changes.
Make sure that clients and management comprehend the scheduling influences, peculiar risks, and how much does weighty requirements changes cost? Then let management or the clients (not the developers or testers) decide if the changes are confirmed.
Only easily-implemented new requirements should be allowed into the project, while moving more complex new requirements into future versions of the application.
It can be helpful if the application’s initial design allows for some adaptability so that later changes do not require redoing the application from scratch.
The project’s initial time-table should allow for some additional time corresponding with the probability of changes.
Try to design some elasticity into automated test scripts.
It is also very useful when code is well-commented and well-documented.
You can use quick prototyping whenever it possible to help clients make sure of their requirements and minimize changes.
Try to move new requirements to a ‘Phase 2’ version of an application, while using the original requirements for the ‘Phase 1’ version.
Pay more attention to initial automated testing on application perspectives.
Pay more attention to ad hoc testing and less on detailed test plans and test cases.
You should cooperate with the interested parties of the project on early stages to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible.