In Software Application Development if the requirements change in the initial stage then it is still OK to adopt the new change in requirements & cost to fix this is less. If the requirements are changing continuously but the changes are communicated well in advance and enough time is given to testing the application then it is not a problem at all. But if the requirement change in late stage of SDLC then cost to fix is very high. In this article I am explaining few necessary things which need to consider when the requirement changes continuously.
In the early stage work with the management and end user to understand how requirements might change, so based on that you should prepare for alternate test strategy and test plan in advance. Initial design should acceptableness which helps to adopt requirement changes in the later stages & avoid the re-doing works again and again.
Let’s discuss what all points need to consider if changing requirements continuously:
- Use of rapid prototyping is best option if possible. So this will help customers feel sure of their requirements and minimize changes.
- To minimize the effort of regression testing later first prepare for risk analysis of changes.
- If possible then new requirements should move to the next Phase of the application. Stick to original requirements in the current Phase.
- Spend adequate time to think of probable changes in initial stages of project.
- Make sure that the code is well documented and commented as well. For developers this helps to make the code changes easily.
- Prepare for requirements traceability matrix that would help to trace what all test case needs update if specific requirement is changed.
- Creating automated testing such a way that if changes in requirement then expected effort is minimum to deal with new changes.
- Generic level test plan should be prepared & more flexible test case should be design (it is not simple to design flexible test cases). Minimize detailed test cases writing, you can go with high level test cases if requirement changes continuously.
- Understand risk involved in ad-hoc testing let’s focus less on comprehensive test plans and test cases.
- Automation test scripts should be created more flexible & adaptive in nature.
- First concentrate on automation testing piece that probably remains unchanged after change in requirements.
- Make sure that management and client understands the cost, schedules & impact of changes in requirement and they are acceptable with the changes.
If same issue still exists then figure out why these requirements are not aligned with realism. You have to re-factor the software development process followed in your organization. So follow Agile Development process might be the GOOD option to go with because it allows you change in requirements in late in Software Development process as well, it is intended for that. Also the end user or customer involvement is on all stages, so customer is aware of what is implementing & if they want to changes in requirement or add new requirement then it can be easily accommodate.
Have you ever worked on such project where requirements were frequently changed, so please feel free to share your experience in comments below that will help for beginners to understand things better. Also you can share this Software Testing article to your friends using following social sharing options, Thanks.
