以前做开发的时候，我们尝试过敏捷，现在回过来想想，当时我们的测试人员比开发更加迷茫，常常会不知道如何开始自己的工作。现在，回到测试的岗位，重新思考这个问题，发现还是很难定义敏捷过程中测试的一些定义，下面是朱少民在程序员杂志上发表的一篇文章，我觉得很有用处，分享之：

　　有一次，当开发人员完成当前Sprint 任务的代码之后，测试人员、开发人员和产品经理一起来浏览产品、从头到尾走一遍，产品经理发现了问题，认为需要对功能进行比较大的修改。这时开发人员估计需要两天时间才能完成代码，但测试人员反对这样做，我们本来只有5天测试时间，加上这次新做的功能比较多、开发代码质量不高，验收测试已经很紧张。如果再延迟两天，测试没法完成。产品经理说，你们不是在用敏捷测试方法，应该测得很快，三天应该能完成测试工作啊!

　　什么是敏捷测试呢?敏捷测试当然不能简单地理解为测得更快，不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说，只有敏捷开发，没有敏捷测试。下面我们将要讨论一下：

　　究竟什么是敏捷测试?

　　敏捷测试有哪些流程改进?

　　测试人员如何面对敏捷测试的挑战?

　　在敏捷测试中如何制定相应的自动化测试策略?

　　什么是敏捷测试

　　假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说，敏捷测试是持续地对软件质量问题进行及时地反馈，如图1所示。

图1 敏捷测试定义的形象描述

　　敏捷测试流程的优化

　　在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也是每个月发布一个新版本。开发周期短，功能不断累加，给软件测试带来很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的主测试计划书，然后再建立每个功能任务的测试计划书，测试计划书有严格的模板，而且需要和产品经理、开发人员讨论，并和测试团队其他人员(包括测试经理)讨论，终得到大家的认可和签字才能通过，仅测试计划经过“起草、评审和签发”一个完整的周期需要一个月。在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点(包括策略、特定方法、重点范围等)列出来可以了。