TDD团队中的测试人员

　　测试驱动开发(TDD)是一种开发方式，它改变了传统软件开发的流程，即首先设计程序，再进行编码与测试工作。TDD采取了很小的增量式开发方式：首先编写一个测试，再编写实际程序代码以通过测试，最后对代码进行改进。这种方式的结果是大量的(通常可达到几千个)自动化测试，能够在几秒钟之内执行完毕。

　　测试人员需要注意到一点，这些高效的自动化单元测试剔除了大多数手工测试的执行。这样一来，我们就需要重新反思是否有必要在TDD团队中继续保留测试人员的角色。

　　从表面上看，无论是否采用TDD，“测试人员”都是团队中必不可少的角色，但实际情况要复杂得多，现在让我们来看看这些复杂性体现在何处：

　　如果你打算开始尝试TDD，那么建议你不要试图在团队中揉合老派的QA与功能测试人员。

　　如果你已经成功地实施了TDD，那么在团队中安排一位专攻测试的成员仍然是有意义的。

　　在TDD中团队中能够取得成功的测试人员与传统的功能测试人员的区别在于，前者具有更扎实的技术背景。

　　QA的兴衰

　　在对“ TDD已死? ”这一主题所展开的一次对话中，Kent Beck(KB)、Martin Fowler(MF)与David Heinemeier Hansson(DHH)围绕着QA与测试展开了激烈的讨论。他们指出了专职测试人员历史的3个发展阶段：

　　堆积QA：通常指机能失调的QA部门，其中充斥着大量的功能测试人员。

　　摒弃QA：对于让程序员负责测试的做法过于自信，在开发过程中摒弃测试人员。

　　当前现状：在项目中引入适当的QA(甚至是功能性的)仍是有必要的。

　　流行于上世纪90年代的堆积QA的做法现在看来似乎已经过时了，许多IT组织已经解散了他们的QA部门，并将测试人员分派到各个敏捷团队中。不过，在许多敏捷团队中，这些测试人员仍在继续着早期的手工测试任务。众多组织仍然受困于延续自20年前的机能失调的测试方法。

　　老派的QA方式之所以出现机能失调的情况，是因为这种方式依赖于大量的功能测试人员。这些测试人员是手工测试方面的专家，但对于技术方面的技能知之甚少。测试人员的专业性决定了他们擅长于对功能的“测试”。但是，老派的QA部门更倾向于(同时也出于商业利益的考虑)让这些测试人员对功能进行“检查”。

　　“检查”的主要特点在于：这种测试 完全 可以实现 自动化 (Bach 与Bolton 2013)。这就意味着“检查”功能可以由程序员完成。至于是应该让测试人员还是程序员进行功能“检查”，这种选择貌似随意，其实不然：无论是发现 bug、进行隔离、汇报、跟踪或是提出修复意见，测试人员都要花费更多的时间(Kaner 2001)。

　　通过手工测试人员对功能进行“检查”的方式让老派的QA变得非常低效。一旦团队培养出“不要测试自己的代码，把它丢给QA去做”这种观念，测试工作就变得机能失调了(KB与DHH在这次对话中的观点)。这种方式发展到一定程度，就会造成效率的不断下降，随着投入的测试人员越多，反而会造成bug数量的不断升高。('Better Testing - Worse Quality'，Hendrickson 2001)

　　摒弃QA是对于手工测试这种机能失调的实践的一种自然反应。之所以本文的标题没有取名为“敏捷团队中的测试人员”，是因为摒弃QA的做法在某些情况下并不可行，比如你的敏捷团队虽然实施了Scrum框架，却没有进行任何自动化单元测试，又或是团队正在进行某些商业现成品或技术(COTS)的软件开发。如果团队中没有设立功能测试人员，则必须实施TDD实践，或是其他任何一种能够生成自动化单元测试的方法。

　　在大多数情形下，选择了TDD就意味着你必须改变程序员的技能、习惯，并且往往还需要改变他们的态度与自我意识。而实现以上这几点并不容易，同时 TDD本身也并非可以一促而就的：“要很好地掌握遗留代码、对单元测试进行适当的隔离、以及集成测试是非常困难的”(Shore 2007)。根据评估，当程序员转为采用TDD实践后，前几个月的生产力会急剧下降。不仅如此，对实践TDD的新手往往要进行几周乃至几个月时间进行手把手的培训(Larman，Vodde 2008)。

　　依我的经验看来，老派的程序员与测试人员之间往往存在着一种共生现象。老派的程序员不喜欢进行单元测试，只要项目中有测试人员，他们就企图蒙混过关。而老派的测试人员也不愿意学习技术知识，只要为程序员找到了足够的bug，他们也同样选择应付了事。老派的程序员与测试人员都希望避免进行任何改变。因此，在我看来，如果程序员已经开始实施TDD实践，再往团队中安置一个功能测试人员就是一个坏主意。

原文转自：http://www.infoq.com/cn/articles/testers-TDD-teams