神话8："单元测试就是设计规格说明书"
无论你采用哪一种开发模式，在开发代码之前你都必须对需求进行思考。虽然TDD的单元测试产物可以让我们理解相当一部分的设计规格说明，但是仍然存在差距。
定义测试用例用于检查需求并不是新鲜事。不管你采用的是什么开发模式，最重要的是针对每一项需求提出这样的问题"我将如何测试它？"，这样你的测试用例是在落实到代码之前就被充分考虑过的，而不是等待将来的"重构"。
神话9："TDD适用于任何项目"
随着项目规模的扩大，执行测试所需要的时间也在增加。这可以通过划分项目和测试范围来解决。但是无论如何都会导致测试运行的频率不一致，这样就需要测试的计划和测试执行的管理，因此，除了白盒测试，我们还需要考虑以下几种测试：
集成测试 - "我需要运行哪些测试来确保新的代码与其关联的代码有效地工作在一起？"
系统测试 - "新的代码在系统层面的功能是够正确，与其他系统工作在一起的流程是否正确?"
回归测试 - "我需要隔多久运行一次回归测试来确保新的代码没有造成非预期的影响？"自动化的回归测试为敏捷开发提供了一张安全网。
用户验收测试 - "TDD不仅需要确保某项功能正确地工作了，还要确保它们对于业务用户来说是可接受的。"
然而，随着项目组的扩大，测试的"自我文档化"（self-documenting）不再可接受，因为参与的项目组成员越多，不同的人对需求的不同理解，项目的风险随之增加。
随着项目规模增加，需要开发的测试代码也大大增加，测试代码的维护工作量也大大增加，对测试自动化的需求也在增加，需要更多的自动化测试用于缩短每个测试周期的时间。
神话10："开发人员和测试人员是水火不相容的"
长久以来，开发和测试之间存在"你我之分"的紧张局面。这其实会是一种"共生共赢"的健康关系，如果能很好地一起正确地工作的话，这种关系可以为顾客产生更高的产品交付质量。
讨论的焦点应该集中在：
· 交付的软件需要满足业务目标（满足需求、按时、控制成本），而不是讨论谁拥有哪一部分流程的权责问题。
· 测试人员在需求收集阶段可以做出什么贡献？如何让他们更好地融入到TDD的过程中。
· 测试人员如何最大化地重用开发过程中产生的各项"资产"？
· 在TDD中是否有一个"传统测试人员"的角色？或者他们是否需要像开发人员一样掌握新的技术来适应新的开发模式？
· 在新的开发和测试工具中，开发人员和测试人员如何互相找到自己需要的东西？
结论
敏捷项目其实是QA领导敏捷过程的一个较好机会；谁是用户和开发者之间的非常好的桥梁，能理解各方面的需要，如何达成以及如何在开发之前就得到保证？
QA除了继续在确保整个系统的演进满足业务目标和需求外，应该对"如何"和"结果"两方面都投入自己的兴趣。但是这同时对QA提出了新的要求，他们必须自己"敏捷"起来，抛弃旧的模式，专注于应用新的技术来优化测试的策略。
