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

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

敏捷测试

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

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


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

然而，对于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中开发的白盒的单元测试的粒度和目标与黑盒测试有所区别。

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

神话3："我们不再需要测试人员、或者自动化工具"

专业的测试人员履行了不一样的职责，与开发同僚们一样是不可或缺的项目组角色之一。

不得不承认：传统的自动化测试工具并没有像厂商们所鼓吹的那样神奇。但是这不意味着我们要放弃自动化工具，我们仍然期待更多更好的自动化工具的出现。

神话4："有了单元测试，手工测试没有存在的必要性了"

手工测试时重复性的劳动，代价高、繁琐、容易出错。然而，虽然TDD能减少一定量的手工功能测试，它并不能废除进一步的黑盒测试的需要（无论是手工的还是自动化的）。