测试是为了保证软件的质量，敏捷测试关键是保证可以持续、及时的对软件质量情况进行全面的反馈。由于在敏捷开发过程中每个迭代都会增加功能、修复缺陷或重构代码，所以在完成当前迭代新增特性测试工作的同时，还要通过回归测试来保证历史功能不受影响。为此我们期望：

　　测试范围足够广：

　　● 测试用例要覆盖所有功能；

　　● 要在各种可能的环境下作兼容性测试；

　　● 系统的稳定性、性能都要测试；

　　测试频率足够高：

　　● 每日构建产生的版本要保证可用；

　　● 每个迭代都需要对历史功能做回归测试；

　　● 释放前或上线后如果打了补丁，就需要回归；

　　但实际情况往往不遂人愿：

　　实际测试周期变短：

　　● 上线时间提前确定，研发进度延期，测试计划被迫延后；

　　● 最后阶段经常会临时增加测试任务；

　　● 所有人都知道还需要再经过一轮测试，但时间没有了；

　　有效测试资源稀缺：

　　● 临时从其他项目抽调的测试人员不能立刻有效的开展测试工作；

　　● “搞不清楚”本项目的研发人员到底是不会做测试还是不愿做测试；

　　因此由于客观上的资源和时间限制，完整的、及时回归测试在人工测试情况下，往往是不可能完成的任务。团队内部也会产生各种争执：

　　● 提交给测试的版本为什么研发人员不先做通过性测试？

　　● 这次代码改动量不大，有必要再花那么多时间回归么？

　　● 当初不是承诺这次修改肯定不会影响以前的功能么？

　　● 怎么不早说要支持Chrome浏览器，现在哪还有时间测试啊？

　　怎么能让现场出现这种低级的Bug，打补丁后为什么不仔细回归一遍？

　　争执越演越烈，最终有团队成员爆发了：“这简直不是人干的活！”。

　　您怎么看待这句话呢？

　　其实话糙理不糙，用更理性的语言翻译一下就是“有些工作不应该以人工的方式来完成”，比如：

　　● 大量机械的、重复性的回归测试；

　　● 结果的正确性不依赖主观判断的测试；

　　● 需要模拟大量数据、大量并发量的测试；

　　● 需要不间断执行的测试（比如7*24小时持续执行）；

　　● 需要短时间内完成的大量测试用例执行（比如完整的功能回归测试）；