这篇文章指出，建立一支成功的软件团队的秘密不在于雇佣明星，而在于保证团队成员拥有多样的强项和技能。它描述了被期望的不同团队成员的特点，以及那些需要监督和矫正的团队成员的特征；本文是为项目和团队经理而写的。
为什么有些软件测试团队成功了而另一些却失败了？只是因为分配给团队的具体任务的性质不同吗？换句话说，成功和失败是预先注定，不受团队的控制的吗？或者，成功的关键仅仅只是集合一群“明星”然后让他们自己干活吗？相反地，也许成功完全取决于有效的团队领导？这里的答案是什么呢？
简短的回答是没有简单的方案。任何团队都必须在自治和受外部管制力量以及团队内部责任做出响应的需要之间进行平衡。雇佣明星显然对团队建设有帮助，但是那不是对成功的保证。
本文探讨了区别高效能测试团队的一些具体特征。目的是帮助软件测试工程师和管理者了解这些特征，以及如何在他们自己的团队中培养这些特征。
一个团队之所以成为一个高效能团队，人们有很多老套的描述方法，比如：“团队中没有自我”，“整体作用大于局部作用之和”。这些都指出一个优秀团队不是一群个体，而是一个有凝聚力的集体。尽管如此，有效的软件测试团队还共有一些更微妙（不太老套）的特征。我们将从探讨这些特征开始。
测试团队有明确定义的角色任务
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 每个团队都需要一个有远见的人来推动它向前进步。
你发现了这些人的性格的共同之处了吗？他们都很饥饿。我不是指他们的饮食习惯（尽管，作为一条惯例，测试人员确实会把带到他们办公室的免费食品狼吞虎咽地吃下去），而是指他们进行软件测试的方法。他们好奇、有预见性、适应性强，并且不惧怕尝试新事物或是问“为什么?”他们在技术和学术上是不断进步的。他们永远不会因为停滞不前而落后。
需要改变方向的类型
在进行下一步前，让我们也看看一些会阻碍测试团队工作的人的类型吧，并探讨一下如何把他们的能量导入更有效的任务中。
- 状态成瘾者（Status Junkie）。软件测试工程师的一个重要任务是在测试过程中精确跟踪进度，包括报告所有错误，以及测试涵盖的具体硬件和软件配置。这些进度和错误信息，一般称为“metrics”，是决定被测试软件是否从alpha测试前进到beta测试，是否从beta测试进展到业内发布，等等的关键输入。需要记住的很重要的一点是，这些和状态相关的信息是达到最终目的的一种方法，而最终是指完成能够产生利润回报的软件产品的开发、测试和发布。收集和表达状态信息本身不应该成为一种终结。如果你发现一个软件测试工程师花在和状态相关的任务上的时间和精力多于他花在实际设计、编写、执行和调试软件测试上的时间和精力，那么你可能就发现了身边的一位状态成瘾者
9 。还有哪些症状可以指示出状态成瘾者？首先，这些人会做出很大努力，非常详尽地告诉你为什么他们无法完成一项任务——而不是尝试用新的方法来解决他们遇到的问题。其次，他们花大量时间忙于他们进行状态报告的表格。我曾见过包含数页文本，多种颜色，令人目眩的图表阵列，但是很少有用信息的状态报告。几年前，在一个特别复杂的项目中，我的一个同事开玩笑说，“我们应该只发布我们的状态报告；它们比我们的产品漂亮多了！”
怎样改造状态成瘾者呢？从积极的一方面来说，你要应对的是一个有良好工作道德和高能量等级的人，而且他理解跟踪错误，测试进度和其他信息的重要性。你的任务是把他的能量集中到正确的方向上，让他（她）在软件测试中控制状态报告这方面的比例。从一种“干涉”开始，向他解释状态报告很重要，但是不能以牺牲建立和测试你实际要发布的产品为代价。然后，限制他（她）的状态报告的规模。当我告诉我的成员，写状态报告就和写一篇新闻报道是一样的时，我收到了很好的效果。那使得他们集中于交流重要的事件，并且使用简洁的形式。最后，确定他们明白你对他们施加的“规则”是灵活的。他们的报告的细节量应该根据情况不同有所变化。如果他们的测试基本是按计划进行的，那么一篇简短的报告就足够了。如果他们在最近的一个开发周期内正在跟踪一个严重问题，那么也许每日（甚至更频繁）的报告都是必要的。
- 智者（Sage） 当你的团队讨论如何对面对新的技术挑战时，可能有人站出来说，“我以前见过完全一样的情形。很久以前在土豚项目中我就已经解决了相同的问题。让我告诉你们我们是怎样做的。”接着他开始详细讲述他以前的成功。问题是他只能提供口头上的解决方案，也许加上他在白板上画的图。实际上他不能提供一整套工作流程或是详细文档。当你问及具体时，他只是像做诗一样地描述并回到白板再画一张图。另外，如果他没有真正理解现在的问题的话，他过去项目使用的方法可能根本无法被采用。
怎样才能从这样的人那里获得具体的结果呢？抛开他的貌似无助的演讲和图画，圣人的经验——至少部分经验——很可能对你的团队来说是很有用的资源。你需要做的是把他的问题分清楚。首先，如果他没有真正理解你们当前的任务，但是想要把一个以前的解决方案硬套进来，在他结束以前就制止他，并针对他的讨论一点一点进行分析。让他讲解他对当前项目的理解，让他作为老师讲解学生的提问。奇怪的是，很快你就会使他相信，他必须再努力理解当前的情况。其次，提出建议，在缺少他以前项目的工作代码模型的情况下，让他基于以前的工作快速为你的项目建立一个新的原型。换句话说，让他“实践他的演说”。在最坏情况下，这会使他明白手头问题的技术方面的难点；在最好的情况下，他会建立一个你的团队可以使用的原型。
- 揽事过多者（The Spread-Too-Thinner）。 正如我们曾提到的，软件工程师工作的挑战之一是需要对不断发生的变化做出响应。有时变化发生的原因来源于你的组织之外——比如，一种新的技术上市。其它时候，变化来源于你的组织内部。比如，在软件进化的过程中你可能需要对设计或是计划的测试序列做出更改。处理这些变化往往涉及多个方面的任务。测试人员必须能够把他们的任务区分出优先级，然后分配好他们的时间来完成这些任务。当最高优先级的任务阻碍了测试进展时，他们应该无缝地进入拥有次高优先级的任务，然后再回到第一个任务。有些测试工程师负责大量任务，但是在任意给定时间只能在很少一部分任务上作出进展，这就是我们所说的“揽事过多者”。这个人很诚实，很勤奋，一心只想帮助团队向着目标前进。当他的工作受阻时，他总是自愿要求更多任务。渐渐地，他承担了太多任务，忙碌着想做所有事情，以至于实际上他无法完成任何事，或者无法对他的高优先级的工作负责。这种情况的另一种变化是“狡猾的躲闪者”。躲闪者与揽事过多者的一个重要区别是：他故意自愿要求做更多任务，甚至超过他可能完成的极限。为什么这么做呢？这样他就可以隐藏在一个任务后来回避做另一个任务：他当前被分配的任务。如果你问及他在任务甲上的进展，他会回答你他忙得没空作那个任务。他在完成乙任务。
怎样把一个揽事过多者或一个狡猾的躲闪者转变成一个能干的团队成员呢？方法差不多：让他集中精力。给他留下定义一个力所能及的任务和目标集合是非常必要的印象，然后把他的能量引到用一种有组织的方式完成这些任务上。起初，你可能需要像酒吧男招待对喝多了的顾客做的那样，让他住手，减少他的任务清单。然后定期检查他的工作，保证他确实在剩余的任务上有所进展。如果你对付的是一个狡猾的躲避者，那你可能需要采取更激烈的措施，每次把他的任务清单减少到一个任务。这将迫使他集中精神，再也无法躲避。
让我们回到优秀测试团队的特征上来。
团队保持连续性
在短时间内建立一支成功的团队是很困难的。你必须雇佣、培训、在发生技术变化时重新培训、计划和在项目目标和需求变化时重新计划。在一段时间内建立一支多次取得成功的团队更加困难。团队成员成熟了，在团队内工作变化，甚至离开，带走了他们的技术，经验，和回忆。
一个团队如何长时间保持成功？在发生变化时它必须保持它的连贯性。这里另一个体育方面的类比是有用的。在美国棒球界，最著名的队伍是
New York Yankees。为什么？因为他们在过去八十年里赢得了太多的冠军，人们把他们称为一个“王朝”。他们成功的秘诀是什么？专注于胜利的所有者，出色的管理者，以及一个不断发现和训练了相继几代明星选手的人事系统。
下面我们将会看到，这些品质同样可以帮助软件开发和测试团队取得成功。
- 人员。我们已经讨论了为何建立一支成功的团队不是简单集合一群“明星”，而是建立一支由拥有不同的、互补的技能，经验和观点的人组成的队伍。确保你的团队永远是为未来做好准备的也很重要。继续我们的体育类比。Yankees
队在二十世纪中期称霸的一个关键是队里的核心选手的运动生涯是相互交叠的。在队里的核心选手开始下滑的时候，教练已经在训练下一个伟大的选手了。在二十世纪二十年代早期，队伍是由
Babe Ruth 率领的。在那个十年的后期，Lou Gehrig的运动生涯的开始重叠了Ruth的晚期。在二十世纪三十年代中期，景况不佳的Lou
Gehrig被年轻的Joe DiMaggio所取代。然后，在二十世纪五十年代初期，Mickey Mantle在中心球场作了运动生涯即将结束的Joe
DiMaggio的替补。这些伟大的选手的运动生涯的交叠确保了球队的成功，尽管其他的队员来了又去。你的软件测试团队应该为未来作出同样的计划。你的团队的经理和高级成员应该培养并交叠下一代的领导。这将保证你的团队保持它的成功，即使在短期的资源缺失情况下（比如团队领导成员抱病或生孩子），甚至在他们辞职的情况下也不会受严重影响。这种交叠的方式也保证了团队成员是交叉训练的，没有一个人是一个“失败点”。这些年我见到数不清这样的例子：在给定的日子不可能进行某个特定的任务，因为，“只有Harry知道怎么弄，但是他今天病了。”
- 制度上的记录。保持团队的连贯性从人员扩展到硬件，软件，以及文档资源等等成员工作需要的东西。建立测试网络，开发测试工具，以及写作解释它们的用法的文档都是重要的任务。一个常常被忽略，不怎么招人喜欢的任务是维护这些资源，特别是文档。尽管如此，花时间和精力做这件事确实帮助团队保持了连贯性；文档代表了团队制度上的记录。人们来来去去，但是拥有精确描述团队角色，任务和工具的最新的图书馆能够帮助后代的团队成员保持团队的成功。
我们将在下一部分讨论有效的管理和管理者的重要性。（如何为你的公司建立坚定的所有权是超越本文范围的一个主题。）
团队既有管理者和又管理
我很小心地选择了这部分的标题；尽管一个团队的管理者对团队的成功至关重要，但是团队全体成员，包括管理者，实施管理的方式却更为重要。
为了团队的成功，管理者必须完成几项任务。他必须管理预算，安排培训，检查物理工作环境（比如，硬件）的建设。但是他还有更重要的职责。
- 在团队框架中实施自我管理。有些人使用一种严格的，自上而下的方式实现管理。他们对所有决定的作出保持中心控制，并引导所有团队成员的每日工作。尽管在一些情况下这种管理是必要的（比如，团队完全是由初级，无经验的工程师组成的），它仍是一个效率很低的模型。如果没有人可以在没有管理者许可的情况下行动，那么团队在管理者不在，或者在等待管理者明确指示的情况下就会瘫痪。在团队成员应该对问题尽快做出反应的情况下，他们不能按照“速度是致命的”的原则行事，而是反其道而行之，因为他们习惯于等待管理者的指示。如果你看篮球，你可能看到过这样的场景：一个队员奋力抢篮板，拿到球，然后，不是快速传球或带球摆脱对方防守，他停下来，目视管理者等待下一步指示。在他这样做的时间里，对手往往就有了恢复的时间，取得优势的机会就被浪费了。作为管理者，你可以为你的团队提供一个详细定义的指导方针和原则的框架，以防止类似的瘫痪出现。鼓励成员自我管理，这样他们在决策时就会作出迅速的反应。这涉及制定有效的软件测试计划。有些人在写计划时默认事情的发展会很顺利。但是众所周知地，当你测试软件时，往往不会顺利。作为管理者，你必须保证所有测试计划带有处理这些问题的偶然性计划。这意味着制定了允许团队成员利用个人主动性的灵活计划。谚语，“计划也是一个动词”对软件测试来说是千真万确的。
- 提供“未完成的议程”。为团队的工作制定方向是最重要的管理任务之一。在这点上我最喜欢的引用来自美国前总统，John
F. Kennedy 的事例。在他的1960年竞选中，他说总统的责任是为国家“在人民前面制订未完成的议程”。对软件测试团队来说，未完成的议程包括一些行为，比如实现测试自动化，或者学习新的技术或平台（比如J2EE）。对管理者来说，这里的关键是为团队的当前项目任务提供短期的战术领导，同时为团队的未来提供长期的策略展望。
我们从提出问题：“为什么有些软件测试团队成功而另一些却失败了？”开始进行讨论。在简单回答和老式的回答之外，我们讨论了团队如何定义他们的角色，如何建立团队内部和团队外部的关系，管理者在团队中需要的个人类型，以及由项目管理者和团队成员共同完成的管理角色在团队成功中所起的作用。
总而言之，在成功团队的特征上没有简单的答案。就像对个人，它是一个环境、特点、和领导的组合。哦，还有，需要勤奋工作！
1 试图在一个没有定义任何“规则”的项目环境中建立并运行一个团队的经验，就和Franz Kafka的作品The
Trial中的主角的遭遇类似；他被指控犯罪，但是又找不出是什么罪。
2
http://www.ibm.com/developerworks/rational/products/rup/
3 "Orchestrating Integration Tests," Software
Testing and Quality Engineering，July 2003。
4 "Testing Java Servlets," Dr. Dobbs Journal，August
2004。
5 如果需要关于软件设计完整概念的详细描述，请看Fredrick Brooks的经典之作，The
Mythical Man-Month.
6 文档类型定义（Document Type Definition）。关于XML和DTD的一个很好的指南：“解码
XML 和 DTD”。
7 我一直很喜欢Abraham Lincoln的这些话：“关于寂静的过去的教条对狂风暴雨的今天是不够的。困难使境况像一堵高墙，我们必须翻越它。由于我们的情况是全新的，我们也必须全新地思考，全新地行动。”
8 "Four Lessons for Software Testers and Their
Managers," The Rational Edge (http://www.ibm.com/developerworks/rational/library/4865.html)
9 Four Lessons for Software Testers and Their Managers,"
- 您可以参阅本文在 developerWorks 全球站点上的
英文原文。
|
