How to test when software changes frequently? [Translation 〕

As an old saying goes: "The only thing that remains unchanged is change ".
In the software development model, one defect of the Most Excellent waterfall model is that it is assumed that there are few or no changes, and the real world is changing every day. Because of this, other development models such as "Rapid Application Development (RAD)" gradually develop to be able to receive changes, and improve the software development model through the planned iteration process.
Although rad can help software developers speed up development, it also brings headaches to testers. Because each change may produce new defects, and there is only one way to find new defects-to conduct a comprehensive regression test-to re-test all the previously tested parts, compare the returned values and find different places.

Note the following two problems:

1) Can I perform a comprehensive test when the software changes frequently?

In fact, this is impossible. However, this problem itself has a problem ^ _ ^, because it is often impossible to test the software in a completely stable environment. This is actually a question: "Can an effective test be conducted when the software changes frequently ?" Can we expect this test to be completed through better use of human resources and other resources? Can we find the expected many defects?
By observing projects using the rad method, I found that the software testing process is very important for discovering defects, and different processes will show different results. Most of the time, our development process is not a simple repetition, so in the RAD environment, we cannot be like in other environments -- try to use various methods to see if we can find some defects.

2) What policies can be used when software changes frequently?

It should take some time to learn how to work in different environments, but some general strategies can be referenced when software changes frequently.
. First, you have to accept this fact-you cannot have 6 weeks to test a software that is changing every day-or your boss won't allow you to use it that long after every software change cycle. The only way is to define a process that can quickly and effectively complete the test task.
. Conduct risk assessment. It is very important to differentiate the risk levels of different test objects, because you can sort the priorities of different test objects and spend less time on simple issues, for higher risks, higher priority and more time and other resources are given.
. You must have a specific working version (baseline version) so that you can compare it during future tests.
. Automated Testing. Using the capture/playback tool, you can use some automation features to help you perform regression testing on the software. You should consider taking some time and money to integrate some tools into your team, so that everyone can learn how to use these tools will be helpful to your work. It is difficult for an organization that does not want to introduce new technologies, such as automated testing tools, to complete tests during frequent software changes. This is like building a house. You must have some proper tools at hand.
. Automated tools can only record and play back your operations, which is not enough. You must specify business requirements, design test cases and test processes, and develop test plans. In addition, if people want to gain more benefits than short-term work during long-term work, they need to consider test cases and test scripts.

Testing is not impossible when software changes frequently, but it requires rapid response, effort, and maintenance of change tracking.
Testing when software changes frequently also requires a team and process with innovative thinking, and the tool does not work on its own, only the best people at work can use it at the right time. It is very challenging to combine tools, people, and processes in the most ideal way.

References: "testing during rapid change" by Randy rice, cqa, CSTE

click here to download