Just like an old proverb: "The only thing is changed". In the software development model, a flaw that has been considered the best waterfall model is that there is little or have not changed, and the real world is changing every day. Because of this, other development models, such as "Rapid Application Development, RAD)" gradually develop into a change in reception, and use these changes by planning iterative processes to improve software development models. Although RAD can help software developers accelerate the speed of development, but also make testers very headache. Because every change is possible to generate new defects, but if you want to find new defects, there is only one way - performing a comprehensive regression test - to test the return value and identify all the parts that have been tested. different places.
There are two problems here, you need to pay attention:
1) Is it possible to conduct a comprehensive test when the software is frequently changed?
In fact, this is impossible. However, this problem itself has problems ^ _ ^, because many times it is impossible to test software in a fully stable environment. This problem is actually wants to ask: "Can I perform effective testing when the software is frequent, can we expect to complete this test through better use of human and other resources? Can we find so many defects expected? Through the observation of the project using the RAD method, I found that the software testing process is very important for discovering defects, and different processes will show different effects. Because most of our development processes are not simple repetitions, they cannot be like other environments - try to see some defects in various ways.
2) What strategies can I use when the software changes frequently?
It should take some time to learn how to work in different environments, but some general strategies can be referred to when software is frequent. First, you must accept this fact - you can't have a 6-week time to test a changed software every day - or your boss will not allow you to use so long after each software change The cycle is tested. The only way is to define a process that can quickly and efficiently complete the test task. Risk assessment. It is very important to distinguish between the risk level of different test objects, because you can use priority to different test objects, only spend less time on those very simple questions, and give higher risks Higher priority and more time and other resources. There must be a certain working version (baseline version) to facilitate comparison when testing in the future. .automated test. Using capture / playback tools can help you return to your software with some automation features. It should be considered to spend some tools into your team, so that everyone will learn how to use these tools will help your work. For an organization that is unwilling to introduce new technologies - such as an automated test tool - is difficult to complete the test during software frequent changes. This is like covering a house, there must be some suitable tools on the hand. Automation tools can only record and play your operation, which is not enough. You must clarify business needs, design test use cases and test procedures, and develop test programs. In addition, if people want to get more benefits than short-term work during their long-term work, they need to consider test use cases and test scripts.
Testing is not impossible when the software is frequent, but it is necessary to quickly respond, work hard to work and maintain the change of changes. Testing when software is frequently changed, there is also a need for innovative thinking teams and processes. Tools will not work, only at work is the best effect on the right time in the work. It is a very challenging thing to make tools, personnel, and processes to achieve an ideal combination.
Reference: "Testing During Rapid Change" by Randy Rice, CQA, CSTE
