我们可以采用什么样的策略呢？

研究每个单独的环境当中需要采用的策略将会耗费过多的时间，这里有一些通用的策略，可以在快速改变的测试环境中使用。

首先，你必须接受一个事实，那就是不可能花去6个星期的时间来测试一个天天都在改变的软件。这就意味着你需要限定测试过程使得他可以快速并有效的进行。

做一个风险程度的估定。知道风险的标准是关键所在，因为你需要在一个较短的时间内来确定你要测试内容的优先级。风险越高，册是的优先级越高。

自动化测试过程。回归测试工具帮助你在短时间内进行重复的测试工作。好的工具需要在软件及培训方面进行重要的投资，但他不能一天不间断的工作。有一些事情需要在自动测试之前考虑并提前做好。

你必须拥有软件的工作标准文档来跟将来的测试进行比较。

你必须定义需求，测试用例和测试环境。工具只能记录并回放基于操作者的操作行为的活动。

数据维护是关键。你将怎样维护这些测试数据？例如，如果你使用回归测试工具来添加一个记录，脚本文件将得到“重复的记录”这样的错误。

这将耗费相当多的时间以及金钱来使得这个工具融入到你们的公司。在此之前还必须对相关人员进行工具使用的培训。因此，必须使人们相信，跟目前工作当中需要建立测试脚本和测试用例这些琐碎的事情相比，这样做对于长期利益的发展是非常有价值的。

在快速多变的环境中进行测试并不是不可能的，但是他需要能够做出快速的响应，灵敏的进行操作，并且与变更的轨迹保持一致。那些不愿意考虑新技术，如自动化测试的公司、组织将不能在快速多变的开发环境中开展有效的测试工作。这就好比是手工工具来盖一座房子，很显然他最终是无法成功的。

TestingDuringRapidChange

As the old adage goes, "the one thing that remains constant is change." In software development, one of the weaknesses of the classic waterfall approach is that it assumes little or no change. The real world changes every day. Because of this, other development models such as Rapid Application Development (RAD) have been promoted to embrace change and use it to refine the software through planned iterations.

While RAD helps software developers get early versions up and running very quickly, it causes testers many headaches. With each and every change is the opportunity to create new defects. The only way to find new defects is to perform a regression test which completely repeats a previous test and compares the results to find differences.

Two questions come to mind: 1) "Is it possible to completely test during rapid change?", and 2) "Which strategies can be used to test rapidly changing software?"

Is It Possible to Completely Test During Rapid Change?

Actually, no. However, that's a trick question because in most cases it is not possible to completely test software even in stable environments¹. The essence of this question might be to ask, "Is it possible to test effectively during rapid change?" Can we expect to make the best use of people and other resources to test software? Can we expect to find the expected number of defects?

By observing projects using RAD, I have observed that a process for testing is essential to finding defects with any degree of effectiveness. Since the norm is to have no repeatable processes for most of what we do in building software, many people test in a RAD environment the same way they do in other environments - try a few cases here and there and look for problems.

Which Strategies Can Be Used?

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

First of all, accept the fact that you do not have the luxury of performing a six week test on software that changes every day. This means you will need to define a testing process that can be performed quickly and efficiently.

Perform a risk assessment. Knowing the level of risk is crucial, since you will need to prioritize your testing efforts to fit within a short window of time. The higher the risk, the higher the testing priority.

Automate your testing. Capture/playback tools help you perform repeatable tests in an unattended session. Good tools require a significant investment in software and training, but it beats working 24 hours a day. Some things to consider before automating:

You must have a working baseline version of the software to perform comparisons with future tests.

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

Data is a key consideration. How will you maintain the test data? For example, if you use a capture/playback tool to add a record, a reply of the scrīpt will get a "duplicate record on file" error.

It takes time and a whole lot of spending money to integrate the tool into your organization. People need to be trained in how to use the tool. In addition, people need to be sold on the long-term benefits as compared to the short-term work required to setup the test scrīpts and test cases.

Testing during rapid change is not impossible, but it does require rapid response, working smart, and keeping track of changes. Organizations that have been unwilling to consider new technologies such as automated testing tools will not be able to effectively test during rapid change. It is like building a house with hand tools - sure it can be done, eventually.

Testing during rapid change also requires a new mindset of organization and processes. Tools alone 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 arriving at the optimal combination of tools, processes, and people that is the challenge.