这篇文章指出，建立一支成功的软件团队的秘密不在于雇佣明星，而在于保证团队成员拥有多样的强项和技能。它描述了被期望的不同团队成员的特点，以及那些需要监督和矫正的团队成员的特征；本文是为项目和团队经理而写的。
为什么有些软件测试团队成功了而另一些却失败了？只是因为分配给团队的具体任务的性质不同吗？换句话说，成功和失败是预先注定，不受团队的控制的吗？或者，成功的关键仅仅只是集合一群“明星”然后让他们自己干活吗？相反地，也许成功完全取决于有效的团队领导？这里的答案是什么呢？
简短的回答是没有简单的方案。任何团队都必须在自治和受外部管制力量以及团队内部责任做出响应的需要之间进行平衡。雇佣明星显然对团队建设有帮助，但是那不是对成功的保证。
本文探讨了区别高效能测试团队的一些具体特征。目的是帮助软件测试工程师和管理者了解这些特征，以及如何在他们自己的团队中培养这些特征。
优秀测试团队的特征
一个团队之所以成为一个高效能团队，人们有很多老套的描述方法，比如：“团队中没有自我”，“整体作用大于局部作用之和”。这些都指出一个优秀团队不是一群个体，而是一个有凝聚力的集体。尽管如此，有效的软件测试团队还共有一些更微妙（不太老套）的特征。我们将从探讨这些特征开始。
测试团队有明确定义的角色任务
John Donne认为，任何软件工程师，任何软件工程师组成的团队，都不是一座孤岛。你可能独自为公司写代码长达数小时，但是你的成功取决于你所在团队的伙伴成员的努力。而你的团队的成功又取决于其它团队的努力。
若想在相互依赖的软件开发和测试中取得成功，团队必须把责任、交付品、以及支配团队成员如何与他人互动、团队之间如何把互动的协议清楚地定义出来。换句话说，团队必须为团队内外的任务建立社会契约；它们定义了团队成员作为个人的角色以及团队在其它团队的大环境中的角色。
为什么这样做是必要的呢？首先，它使得团队集中于实现它的目标；没人需要像侦探一样去发现目标究竟是什么，也无需像律师一样去为目标辩护。
第二，如果没有这样一份社会契约，一个软件项目，或任何具有复杂人员结构的企业，都将会像一个“没有法制的国家”那样工作。换句话说，控制项目团队及其成员如何工作的过程将仅仅只基于某些具体相关人员的个人经验，个人判断，以及失败经历。没有清楚定义，清楚记录下来的可供每个人遵循的规则集。 1 项目的成败将完全依赖于那部分人预见问题、领会他人问题和无私为项目更好完成寻求路径的能力。在这样的情况下，有多少人能获得你的信任呢？
详细定义的开发和测试流程，控制软件项目的程度各有不同，取决于项目环境。有些项目是围绕一个详细定义的、全面的过程来组织的，比如 IBM Rational Unified Process，简称 RUP 2 ；而另一些项目则用了比较特别的方式。在后一种情况下，软件测试团队必须从起草它的角色并与其他项目团队建立社会契约开始。在前一种情况下，定义测试团队的角色的工作量稍小，但是项目领导不能简单地说，“我们按照过程进行。”他们必须考虑项目独特的要求和需求。正如 Thomas Watson 先生经常说的，“你必须记得，要思考！”
测试团队是多样的
现在，当人们听到“多样性”这个词，他们会想到关于近来保证公司劳动力方面的事情，公司的劳动力大致反映整个社会的宗教，种族的组成部分。当你组建软件测试团队时，也必须考虑到团队成员的技能，个性，以及经验的多样性。尽管你可能认为软件测试团队成员应该相对来说都是差不多的，最强的团队却是由一组具有多样性技能的个体成员组成的。让我们详细分析这点；然后我们回顾一下你在组建你的团队是需要组合的性格和技能类型。
人们经常用体育上类似的情况来描述商业或工程团队的运作；实际上，这种类比在商业通信上已经很老套了。尽管如此，有趣的是，在某一段时间这些陈词滥调曾反映了精确和新颖的思想。比如说，如果你和我一样在美国 Massachusetts 的 Boston 附近长大，而且你对体育不是毫无兴趣，那么你很快就会知道 1967 年Boston Red Sox 棒球队的故事。那一年，这支队伍在二十年的失败后赢得了它的第一个联赛冠军。他们不是依靠组建一支全明星队伍，而是组建了一支拥有少数“明星”，多数有潜力但缺乏经验的年轻队员，以及有经验，但不出名，可以担任多种角色的队员的队伍。那是一支多样化的队伍，而且巧合地，他们非常有激情。它是成功的，不仅因为有些队员在整个赛季表现出色，还因为整个队伍的技术和性格构成很合理。
同样类型的多样性在建立一支成功的软件测试团队中也很重要。相对来说，量化技能比较容易，比如使用Java之类的具体程序设计语言的水平，或者使用J2EE之类结构工具的经验。但是怎样评价其他经验、思维过程、爱好、实践能力、见解等等这些你在团队成员身上需要的东西呢？
测试团队应有的类型
在一个理想世界里，你可以根据你的项目需求从一个“性格类型”库里选择组建一支测试团队，几乎和你为一出喜剧或一部电影选择演员阵容是一样的。你想要什么类型来保证团队的成功呢？让我们来看一些可能性。
早期采用者（Early Adopter）。软件工程的一个方面是“永恒的变化”同时带来的喜悦和痛苦。就在你觉得你已经掌握了一种技术或工具的最新情况时，一个新的版本或产品发布了，你又落后了。而且你别无选择的要更新你的知识：你必须努力跟上最新的进展。如果你停滞不前，你很快就会掉队。因此，在你的团队里你需要一个喜欢探索最新软件并为你的团队的软件测试环境推荐新插件的人。
持续采用者（Constant Adapter）。这个人根据团队的具体需要改编新的和已有的软件工具，是早期采用者的补充。比如，假设早期采用者找到了一种帮助数据库管理员从突发失效中恢复的工具。持续采用者会学习如何使用该工具，然后把它用于另一种目的，使得测试团队成员可以重建数据库并在他们进行了一系列测试后恢复一个“干净”的测试环境。
开心的集成者（Happy Integrator）。比管理计划耗费时间长，发现严重的、不易调试的问题，而且通常被认为比其他类型的测试次要的测试是什么类型呢？答案是：集成测试。现在，似乎已经没有团队真正为他们的产品写全部代码了。取而代之，他们使用其他公司提供的代码或公开源代码来构建他们的产品的主要部分。对多来源的代码进行集成测试与对单来源的代码进行集成测试是很不同的。你必须在集成的子系统之间验证产品的操作，并考虑到子系统的限制（以及潜在的缺口 3 ）。这种测试令人疯狂，因为它涉及理解和破译子系统之间的数据和进程流。尽管如此，不幸的是，有些人实际上非常喜欢这种“侦探工作”。
有经验的挖掘者（Experienced Miner）。有一个关于老煤矿工不需要地质数据来发现煤矿点的故事。他做矿工的时间太久了，以至于他可以凭直觉找到煤矿并用十字镐的一次简单回转把它敲松。他可以感觉到正确的敲击位置，这样岩石的外壳就会裂开显出煤矿，正如雕塑家可以精确知道在石头的什么位置而用凿子敲击一样。有些人在测试软件时是这样的：不管情况如何，他们都可以找到正确的位置来运行程序以发现关键的缺陷。有时这种技能是基于对正在测试的软件的经验的。比如说，对Java servlet有直接设计和操作经验的人在发现基于servlet的程序 4 的错误上很拿手。在其他情况下，根据对相似类型的项目的经验，一个软件测试工程师可能会准确知道在哪里找“致命缺陷”。他们可能曾在有相似设计或管理问题的项目上工作过。比如说，有些软件设计就是必须在开发和测试中 5 根据市场和技术变化不断改变和进化。
不知疲倦的革新者（The Indefatigable Innovator）。这是总能够通过新的方法发现问题的人。我可以不客气地说，我已经在很多项目团队中担任过这个角色。很久以前，一个很短的通知叫我换个任务，从一个有趣的项目换到一个不怎么有趣的项目。在试图最好地利用一个糟糕情况的过程中，我决定设计构建一个新的测试服务器软件配置定义和跟踪工具，它是基于一个XML数据库的。当我与这个不愉快的项目的不愉快团队的另一个成员讨论这个想法时，她很悲伤地看了我一眼，警告说，“不要尝试任何有创造性的东西。”在项目当时（杂乱无章）的状态下她感到无比的压抑，以至于她看不到对旧问题尝试新方法的好处。而我作为项目中的新成员，我下决心要学习一种有用的新技能，因此我理由不去尝试一些不同的方法。尽管我永远无法实现我的最终目标——完成一个自动建立复杂测试服务器配置的工具——我还可以学到很多关于XML DTD 6 设计的东西并定义（基本人工）一个量化复杂服务器配置的方法。
远见者（Visionary） 尽管不知疲倦的创新者总是能发现实现战术问题的方式，但发现更高级的，策略性问题的解决方案的却是远见者。团队需要一个能看到“蓝图”的人——对如何进行软件测试具有广泛认识，而且对你的具体程序有深入认识的人。团队很容易陷入把已有解决方案用于新问题的陷阱。有时候这是最实用的方法，但是在另一些情况下，你必须重新思考 7 并设想新的解决方案。技术变化在以不断增加的速度进行着；“在过去”可能指昨天，停滞不前等于落后。 8 每个团队都需要一个有远见的人来推动它向前进步。
你发现了这些人的性格的共同之处了吗？他们都很饥饿。我不是指他们的饮食习惯（尽管，作为一条惯例，测试人员确实会把带到他们办公室的免费食品狼吞虎咽地吃下去），而是指他们进行软件测试的方法。他们好奇、有预见性、适应性强，并且不惧怕尝试新事物或是问“为什么?”他们在技术和学术上是不断进步的。他们永远不会因为停滞不前而落后。
