通过自动化的捕获测试人员的操作过程，并且将他们的键盘和鼠标点击事件文档化，测试人员可以把更多的时间放在有趣的、增值的活动上，例如测试那些自动化很难实现，或者是根本不可能实现的复杂测试场景。虽然通过手工测试寻找bug是一个耗时的、代价高昂的过程，但是如果不采用这种手段而遗漏了BUG，代价会更高。

神话5："不再需要用户验收测试"

在敏捷开发中，用户验收测试通常用于与顾客一起解决"不正确的需求"的问题，而不是用于纠正功能问题。

当用户初定义需求时，他们是基于自己的初始想法和愿景来定义的。当他们看到"活生生的"真正的系统后，他们总是会有不同的、额外的需求。虽然敏捷方法可以减少这种情况发生的频率，但是也不可能杜绝，因此也不可避免地需要用户验收测试。

神话6："自动化是不可能的"

在敏捷项目的早期阶段开展自动化测试通常是很困难的，但是随着系统的演进，某些方面稳定下来之后可以开始实施自动化测试了。

洞悉自动化测试开展的正确时机并不容易，因此，使用某些技术，让早期的手工测试可以顺利过渡到自动化测试是很关键的。如果早期的测试设计和手工测试可以被很好地记录下来，以备重用的话，后面的自动化测试将大大受益。

神话7："开发人员拥有足够的测试技巧"

如果测试是很容易的，那么每个人都可以做，则每次我们都可以发布和交付优质的代码。一个独立的测试组的目标是作为第三方、能够从全局出发、验证和确认软件功能的质量。而开发人员趋向于证明系统是正常工作的。一个好的测试者会倾向于"假设"某些场景的出现，再加上业务用户的测试，则确保系统满足预期目的将变得容易。

虽然可能引起很多开发人员的争辩，但是事实上很多开发人员不愿意花很多时间去先写测试，然后开发代码来证明测试通过了。

神话8："单元测试是设计规格说明书"

无论你采用哪一种开发模式，在开发代码之前你都必须对需求进行思考。虽然TDD的单元测试产物可以让我们理解相当一部分的设计规格说明，但是仍然存在差距。

定义测试用例用于检查需求并不是新鲜事。不管你采用的是什么开发模式，重要的是针对每一项需求提出这样的问题"我将如何测试它？"，这样你的测试用例是在落实到代码之前被充分考虑过的，而不是等待将来的"重构"。

神话9："TDD适用于任何项目"

随着项目规模的扩大，执行测试所需要的时间也在增加。这可以通过划分项目和测试范围来解决。但是无论如何都会导致测试运行的频率不一致，这样需要测试的计划和测试执行的管理，因此，除了白盒测试，我们还需要考虑以下几种测试：

集成测试 - "我需要运行哪些测试来确保新的代码与其关联的代码有效地工作在一起？"

系统测试 - "新的代码在系统层面的功能是够正确，与其他系统工作在一起的流程是否正确?"

回归测试 - "我需要隔多久运行一次回归测试来确保新的代码没有造成非预期的影响？"自动化的回归测试为敏捷开发提供了一张安全网。

用户验收测试 - "TDD不仅需要确保某项功能正确地工作了，还要确保它们对于业务用户来说是可接受的。"

然而，随着项目组的扩大，测试的"自我文档化"（self-documenting）不再可接受，因为参与的项目组成员越多，不同的人对需求的不同理解，项目的风险随之增加。

随着项目规模增加，需要开发的测试代码也大大增加，测试代码的维护工作量也大大增加，对测试自动化的需求也在增加，需要更多的自动化测试用于缩短每个测试周期的时间。

神话10："开发人员和测试人员是水火不相容的"

长久以来，开发和测试之间存在"你我之分"的紧张局面。这其实会是一种"共生共赢"的健康关系，如果能很好地一起正确地工作的话，这种关系可以为顾客产生更高的产品交付质量。

讨论的焦点应该集中在：

交付的软件需要满足业务目标（满足需求、按时、控制成本），而不是讨论谁拥有哪一部分流程的权责问题。
测试人员在需求收集阶段可以做出什么贡献？如何让他们更好地融入到TDD的过程中。
测试人员如何大化地重用开发过程中产生的各项"资产"？
在TDD中是否有一个"传统测试人员"的角色？或者他们是否需要像开发人员一样掌握新的技术来适应新的开发模式？
在新的开发和测试工具中，开发人员和测试人员如何互相找到自己需要的东西？
结论

敏捷项目其实是QA领导敏捷过程的一个机会；谁是用户和开发者之间的佳桥梁，能理解各方面的需要，如何达成以及如何在开发之前得到保证？

QA除了继续在确保整个系统的演进满足业务目标和需求外，应该对"如何"和"结果"两方面都投入自己的兴趣。但是这同时对QA提出了新的要求，他们必须自己"敏捷"起来，抛弃旧的模式，专注于应用新的技术来优化测试的策略。