6． "自动化是不可能的"

　　在敏捷项目早期实现自动化通常很困难，但是随着系统的发展和成长，某些方面已经确定，这时该进行自动化部署了--通过自我修复脚本等处理改动。

　　开始的时候，用户与QA的所有测试几乎都是手动的，但是如果能够抓取并重用这些测试活动和设计，这对以后的工作了是有益的。

　　自动化的时机很难掌握，因此一定要使用能够先支持手动测试而后可以将其发展为自动测试的工具。

　　7. "开发人员都有足够的测试技能"

　　前提是测试简单到所有人都可以做，并且每次提交的代码都是完美的。可惜，许多企业都只在开发人员的编码技术和为他们提供新的集成开发工具上投资，而忽视了发展他们QA团队的测试技能，或者没有为他们提供与开发人员同样有效的工具。

　　一个独立的测试团队像一个客观的第三方，可以清楚地看清"全局"，能够验证可交付产品的功能与质量。虽然开发人员会尽力提供所需的系统功能，但是一个的测试人员还是要客观地提出"万一……"之类的问题。如果你还考虑到了商业用户测试，那你更有可能完成一个符合要求的系统。

　　后，虽然下面的观点可能引起争议，我还是要说大多开发人员实际上并不想花大量的时间先写测试再写代码来验证测试。如果以下描述的协作过程，开发人员可以获得足够的功能测试方面的帮助，从而集中精力编写、稳定的代码。

　　8． "单元测试是设计说明书的全部"

　　不管用什么开发方法，在编写代码之前都要想清楚需求。虽然TDD说"做得不错"可以代表设计说明中的很大一部分已经完成，我们仍然需要考虑单元测试中的一些空白。还有其它同样可行的方案。TDD要验证需求采集的准确性，而他们的依据并没有得到历史的证明。

　　用定义测试用例的方法来验证需求的准确性与简洁性已不是什么新概念。比如V模型，是一种了解测试需求的有效方法--通常指功能性需求。像TDD一样，如果业者比较严格，而开发过程比较灵活，那么V模型以及其它模型没有办法了。软件工程并不像机械工程，强制顺应只会浪费精力。不管你选择了哪种方法，都要问每个用户需求："我怎么来测试这个？"关键是要在代码构建前检查测试用例，否则你会花费更多的时间进行代码重构.

　　通过协作对需求进行精简以后，开发人员可以拿到一份比较稳定的说明文档，这份文档可能会较少地发生变动，因为它已经经过了多方面的评定。

　　9． "TDD适应于任何项目"

　　随着项目规模的增大，进行测试的时间也越来越长。这个问题可以用对项目和/或测试进行划块的方法解决。无论哪种方法都会产生要根据其与当前代码的相关度运行的测试。这导致了对测试计划和执行管理需求。为了获得较高的效率，除了白盒测试，你还需要考虑：

　　集成测试??"我需要哪些测试来保证新代码与其它代码能够无缝合作？"

　　系统测试??"新代码支持的功能与系统或其它系统的功能结合密切吗？"

　　回归测试??"为了保证新代码不会产生不可预料的反作用，我需要以多大的频率运行回归测试？"自动回归测试可以有效地验证敏捷开发技术。

　　用户验收测试??"虽然TDD（与业务用户协作）可以保证某个特定的功能能够正常工作，但是经过各种各样的变动之后，累积的影响还能被用户接受吗？"

　　然而，在的环境下是无法将这些测试阶段当作一系列独立的活动的。通常，每次我们加入新代码的时候，需要同步进行这些测试。随着项目团队（及测试）规模的扩大，测试也变得无法"自我描述（self-documenting）"。项目的参与人越多，项目越容易受到各种对说明文档的不同解释的影响--对这些定义的误解正是导致失败的原因。

　　随着项目规模的增大，需要编写的测试代码也越多。任何测试代码都需要在应用的整个生命周期中得到支持--这极大地增加了维护的难度。

　　随着测试负担的提高，项目需要增加自动测试来小化人力干预并减少进行这些测试所需的时间。

　　10． "开发人员与测试人员，是油与水的关系"

　　开发人员与测试人员自诞生之初是"他们与我们"的关系。这通常是一种健康的共生关系。如果处理得当，两个团队之间互助的关系可以为客户提供更高质量的产品。

　　应该重点讨论的是：

　　?满足业务目标的软件交付（满足要求、及时、并且控制在预算内），

而不是谁控制过程中的哪一部分。

　　?需求采集阶段测试人员怎样参与到TDD过程中？

　　?测试人员如何大程度地重用开发阶段中创建的资产？

　　?TDD中有没有"传统的测试人员"？他们（像开发人员）是否应该学习新技能以适应新的范例？

　　?测试人员与开发人员在利用先进的软件开发和测试工具的时候如何发挥互助的作用？

　　正如开发人员的软件工具和方法使开发方式发生了转变一样，下一代自动测试工具也为测试人员带来了新的机遇，使他们可以在交付周期中更早地进行自动测试而不会遇到传统的自动测试工具所带来的繁重的脚本维护负担。

　　总结

　　敏捷项目实际上是让QA部门引领敏捷过程的好机会??没有人比他们能更好地将用户与开发人员联系到一起、了解两者的要求、满足他们的要求并保证在部署之前完成所有工作。QA除了要继续保证整个系统的进展能够满足业务目标并符合要求，他们还应该在决定结果及怎么做上有优先权利。这需要QA人员能够灵活应变，抛弃原有的范例并集中精力研究技术以获得优的测试方法。