模板
教程
环境
性能
功能
管理
高效能软件测试团队：管理者和团队领导指南
为什么有些软件测试团队成功了而另一些却失败了？只是因为分配给团队的具体任务的性质不同吗？换句话说，成功和失败是预先注定，不受团队的控制的吗？或者，成功的关键仅仅只是集合一群“明星”然后让他们自己干活吗？相反地，也许成功完全取决于有效的团队领导？这里的答案是什么呢？
简短的回答是没有简单的方案。任何团队都必须在自治和受外部管制力量以及团队内部责任做出响应的需要之间进行平衡。雇佣明星显然对团队建设有帮助，但是那不是对成功的保证。
本文探讨了区别高效能测试团队的一些具体特征。目的是帮助软件测试工程师和管理者了解这些特征，以及如何在他们自己的团队中培养这些特征。
优秀测试团队的特征
一个团队之所以成为一个高效能团队，人们有很多老套的描述方法，比如：“团队中没有自我”，“整体作用大于局部作用之和”。这些都指出一个优秀团队不是一群个体，而是一个有凝聚力的集体。尽管如此，有效的软件测试团队还共有一些更微妙（不太老套）的特征。我们将从探讨这些特征开始。
测试团队有明确定义的角色任务
John Donne认为，任何软件工程师，任何软件工程师组成的团队，都不是一座孤岛。你可能独自为公司写代码长达数小时，但是你的成功取决于你所在团队的伙伴成员的努力。而你的团队的成功又取决于其它团队的努力。
若想在相互依赖的软件开发和测试中取得成功，团队必须把责任、交付品、以及支配团队成员如何与他人互动、团队之间如何把互动的协议清楚地定义出来。换句话说，团队必须为团队内外的任务建立社会契约；它们定义了团队成员作为个人的角色以及团队在其它团队的大环境中的角色。
为什么这样做是必要的呢？首先，它使得团队集中于实现它的目标；没人需要像侦探一样去发现目标究竟是什么，也无需像律师一样去为目标辩护。
第二，如果没有这样一份社会契约，一个软件项目，或任何具有复杂人员结构的企业，都将会像一个“没有法制的国家”那样工作。换句话说，控制项目团队及其成员如何工作的过程将仅仅只基于某些具体相关人员的个人经验，个人判断，以及失败经历。没有清楚定义，清楚记录下来的可供每个人遵循的规则集。 1 项目的成败将完全依赖于那部分人预见问题、领会他人问题和无私为项目更好完成寻求路径的能力。在这样的情况下，有多少人能获得你的信任呢？
详细定义的开发和测试流程，控制软件项目的程度各有不同，取决于项目环境。有些项目是围绕一个详细定义的、全面的过程来组织的，比如 IBM Rational Unified Process，简称 RUP 2 ；而另一些项目则用了比较特别的方式。在后一种情况下，软件测试团队必须从起草它的角色并与其他项目团队建立社会契约开始。在前一种情况下，定义测试团队的角色的工作量稍小，但是项目领导不能简单地说，“我们按照过程进行。”他们必须考虑项目独特的要求和需求。正如 Thomas Watson 先生经常说的，“你必须记得，要思考！”
测试团队是多样的
现在，当人们听到“多样性”这个词，他们会想到关于近来保证公司劳动力方面的事情，公司的劳动力大致反映整个社会的宗教，种族的组成部分。当你组建软件测试团队时，也必须考虑到团队成员的技能，个性，以及经验的多样性。尽管你可能认为软件测试团队成员应该相对来说都是差不多的，最强的团队却是由一组具有多样性技能的个体成员组成的。让我们详细分析这点；然后我们回顾一下你在组建你的团队是需要组合的性格和技能类型。
人们经常用体育上类似的情况来描述商业或工程团队的运作；实际上，这种类比在商业通信上已经很老套了。尽管如此，有趣的是，在某一段时间这些陈词滥调曾反映了精确和新颖的思想。比如说，如果你和我一样在美国 Massachusetts 的 Boston 附近长大，而且你对体育不是毫无兴趣，那么你很快就会知道 1967 年Boston Red Sox 棒球队的故事。那一年，这支队伍在二十年的失败后赢得了它的第一个联赛冠军。他们不是依靠组建一支全明星队伍，而是组建了一支拥有少数“明星”，多数有潜力但缺乏经验的年轻队员，以及有经验，但不出名，可以担任多种角色的队员的队伍。那是一支多样化的队伍，而且巧合地，他们非常有激情。它是成功的，不仅因为有些队员在整个赛季表现出色，还因为整个队伍的技术和性格构成很合理。
同样类型的多样性在建立一支成功的软件测试团队中也很重要。相对来说，量化技能比较容易，比如使用Java之类的具体程序设计语言的水平，或者使用J2EE之类结构工具的经验。但是怎样评价其他经验、思维过程、爱好、实践能力、见解等等这些你在团队成员身上需要的东西呢？
