While RAD helps software developers get the first versions very quickly, it causes many headaches testers. With each change, is the possibility of creating new defects. The only way to find new defects is to perform a regression test that repeats a previous test completely and compares the results to find differences.

Two questions come to mind: 1) Is it possible to test during the rapid evolution ", and 2)" What strategies can be used to quickly test the evolution of the software? "

Is it possible to test in the rapid evolution?

Actually, no. However, it is a trick question, because in most cases it is not possible to test software, even in stable environments1. The essence of this 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?

Observing projects using RAD, I observed that 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 as they do in other environments - try a few cases here and there and look for problems.

What strategies can be used?

It takes time to learn what works in each unique environment, but here are some strategies that can be used for testing during the rapid evolution:

First, accept the fact that you do not have the luxury to conduct a six-week test software that changes daily. That means you'll need to define a testing process that can be performed quickly and efficiently.

Perform a risk assessment. Knowing the level of risk is crucial, because you will need to prioritize your efforts to adapt to the test in a short time window. The higher the risk, more testing first.

Automate your tests. Capture / playback tools help you make tests repeatable 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:

You must have a basic version of the software for comparison with future tests.

You must define requirements, test cases and test scenarios. The tool can record and playback, depending on what the user performs actions.

The data is a key element. How will you keep the test data? For example, if you use a capture / playback tool to add a folder, a response from the script will get a "duplicate record in the file error.

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.

Testing during the rapid evolution is not impossible, but it requires a rapid response, work smart, and track changes. Organizations that have not been 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 - that 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 is the challenge.