Changing requirements and implications on testing

An ideal software development cycle involves a process whereby the requirements are frozen pretty early and the entire cycle happens with those frozen requirements. And if requirements do need to change, then a major impact analysis needs to happen, and the change is thoroughly studied before any change is taken. However, in the real world (and something that is increasingly acknowledged by incremental and Agile software methodologies), requirements can and do change and it is better for the software industry if there is a lot more effort put in to figure out how to incorporate the world of changing requirements. One of the folks impacted by changing requirements are the testing team, and once should evaluate how they can respond to such changing requirements. Let us start off by calling it a common problem and a major headache, and then work out what we can do. Here are some steps:
• Work with the project's stakeholders early on to understand how requirements might change (stakeholders have a much better idea on whether the requirements are fully known and stable) so that alternate test plans and strategies can be worked out in advance, if possible.
• It's helpful if the application is initially designed in a manner that allows for adaptability so that later changes do not require redoing the application from scratch, or at least minimise the amount of effort required for change.
• Coding practices of commenting and documenting, if followed religiously, makes handling changes easier for the developers.
• Another way to minimise the need for changing requirements is to present a prototype to the stakeholders and end users early enough in the cycle. This helps customers feel sure of their requirements and minimize changes.
• The project's initial schedule should allow for some extra time commensurate with the possibility of changes. Better to build such a time in the schedule.
• If possible, and if there is some amount of flexibility in negotiating relations with the client, try to move new requirements to a 'Phase 2' version of an application, while using the original requirements for the 'Phase 1' version. This however does not work if the changes affect the workflows directly.
• Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application. This should be possible if there is a good change control process in the project.
• Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. This is typically done by delineating a proper change control process and explaining this to the stakeholders along with examples if necessary. Only after this, let management or the customers decide if the changes are warranted.
• Changes have a major effect on test automation systems, especially if there is a change in the UI of the application. Hence, you need to be sure that the effort put into setting up automated testing is commensurate with the expected effort required if there is change which causes re-doing of the test effort.
• Try to design some flexibility into automated test scripts. Not easy, but if you have initial ideas of change this should be possible.
• Focus initial automated testing on application aspects that are most likely to remain unchanged. This ensures that later test automation effort is done when there is some stability in the requirements.
• Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
• The last plan may seem very strange to a test manager. Focus less on detailed test plans and test cases and more on ad hoc testing; keep in mind however that this entails a certain risk.
Overall, when requirements are changing, teams also need to be more flexible to respond to such changes.