对于敏捷测试，可定义如下：

　　项目中使用敏捷技术的相关测试实践，开发作为测试的顾客，强调测试先行的设计理念。在敏捷开发中，测试被整合到整个开发的生命周期中。

　　敏捷测试

　　敏捷将被越来越多的人所接受，这很容易理解，如果从开发者和用户的角度去看的话。

　　对于用户，他们不愿意花费大量的时间被人盘问关于整个系统的需求和过程，而且需要评审大量的规格说明，而且开发团队可能会在后期拿着这些规格说明来与他们"对质"。

　　对于开发人员，他们希望发挥自己的想象空间和创意，不愿意遵循规格说明的约束，尤其是在他们看到有更好的解决方案的时候。

　　然而，对于QA人员来说，敏捷意味着什么呢？敏捷会给他们带来诸多不便。在理想的世界里，他们会获取一个"已完成"的产品来针对规格说明进行验证。现实中，他们被要求对"正在移动"的目标进行验证，这是违背直觉的。这意味着一些技术和自动化的使用变得困难，需要新的测试方式。

　　所有敏捷方法都有一个共同点，就是它们对QA角色造成影响。

　　随着TDD（Test Driven Development）的出现，有人开始质疑QA存在的必要性（既然TDD的关键就是测试）。但是，最重要的问题是QA需要直接全程参与到敏捷过程中，作为团队的整体对测试进行设计，与此同时，需要应对需求和解决方案的不断演变。

　　QA需要知道敏捷方法论的真正影响，对业界关于敏捷测试的各种"神话"作出正确的诠释和回应，以下列举了10大著名的"神话"：

　　神话1："你只需要单元测试就行了—TDD的测试是足够的"

　　这显然是不对的。即使是狂热的敏捷开发者也意识到需要包括很多其他的测试技术。例如，Scott W . Ambler就在他的FLOOT（Full Life Cycle Object-Oriented Testing）方法论中列举了21种不同的测试技术，包括白盒测试、黑盒测试、回归测试、压力测试和用户验收测试（User Acceptance Testing），参见http://www.ambysoft.com/essays/floot.html

　　TDD中的程序员依赖这些测试来验证他们代码的正确性。如果需求（或者说测试用例）没有被正确地描述，那么你可能构建了足够健壮的代码，但是不能满足目标。

　　因此，大部分敏捷项目包括调查性质的测试（黑盒），用于补充白盒的测试。好的调查性质的测试能尽早揭露开发人员遗漏的问题。

　　神话2："你可以重用单元测试来构建回归测试套件"

　　有些TDD的追捧者提出传统的测试不再需要，因为每一行代码都有相应的单元测试用例了；他们认为，通过重新组合单元测试，可以替代从用户验收测试到回归测试的所有测试类型。

　　虽然这听起来很诱人，但是这不现实，因为：TDD中开发的白盒的单元测试的粒度和目标与黑盒测试有所区别。

　　单元测试的总体目标是用于证明代码是如预期般工作的，而回归测试的目的是确保修改的代码不会引起非预期的结果。两者存在的意义是不一样的，例如，"检查某个属性的日期格式是正确的"，就与"对于给定的输入，检查其值具有预期的日期"不一样。