How to Test Software when requirements are changing

The cascade approach in software development considers that the requirement wouldn’t change during the entire software development. It is major weakness with the above model of approach as the real world changes every day. SO other models are used for developments, like flexibility, Rapid Application Development (RAD) and Extreme Programming (XP) was promoted to embrace change and use it to improve the software provided by iterations.

RAD helps software developers to make the first versions very quickly. This will cause many headaches to testers. With every change there is a possibility to create new defects. The only way to find new defects is to perform a regression test that repeats a series of previous test cases whose results will compare with previous results to find the differences.

In rapid development whether it is possible to test?
Truly say no. This one is a tricky question because even in a stable environment it is not possible to test clean. So in rapid change environment the question could be asked: "Is it possible to test effectively in the rapidly changing?" Can we expect to make the best use of people and other resources to test the software? Can we expect to find the number of defects?
In RAD the process control is essential to find defects with any degree of effectiveness. Since the standard is not to have a repeatable process for most of what we do in building software, many people in a test environment in RAD try a few test cases here and there and look for defects. Which is very difficult to find out the defects?

What strategies can be used?
It takes some time to study which method will works in each which environment. The case is that there should be a unique strategy for a unique system or environment. But there are some strategies that can be used for testing during the rapid evolution:
First, accept the fact that there is no time of luxury to conduct a six-week test for software which changes daily. That means there is a need to define a testing process that can be performed rapidly and efficiently.
Second, perform a risk assessment. Knowing the level of risk is crucial, because the need to prioritize the efforts to adapt to the test in a short time window. Higher the risk, more testing should be done.
Automate your tests. Capture / playback tools help to make the tests repeatable and unattended in a session. Good tools require a significant investment in software and training, but it beats working 24 hours a day. There are things to consider before automation:
There should be a basic version of the software for comparison with future tests.
Requirements, test cases and test scenarios should be defined. The tool can record and playback, depending on what the user performed actions.
The data is a key element. Keeping the data is the main element is testing.
It takes time and lots of money to integrate the tool in your organization. People need to be trained to use the tool. In addition, people need to be sold on long-term benefits in relation to short-term work needed to install test scripts and test.

Conclusion
Testing during the rapid evolution is possible, but it requires a rapid response, smart work, and traceability. Organizations that is not willing to consider new technologies such as automated testing tools will not be able to test effectively during rapid change. It is like building a house with hand tools - which it can be done, eventually.
Testing during the rapid development also requires a new mindset and organizational processes. Tools are not the answer. There must be a process that can be executed quickly and makes the best use of people and time. It is to the optimal mix of tools, processes, and people that make the challenge done.