从技术角度看软件测试工程师的分工模型(2)

　　从提交的bug质量上，很容易看出一位工程师的技术和能力，如果P6发现的bug，跟P4差不多，那怎么好意思继续混下去。下面我们再从另一个维度来比较，那就是：是否专注在一个project里面，请看表格：

　　讲到这里第二点“测试工程师的分工”就讲完了。P4工程师的考评最简单最好量化，他只要按照文档，完成一定功能点分数的测试，就可以了。在执行过程中，P4也不需要大伤脑筋，如果有压力也是工作量的压力。假如P4工程师感到执行测试很困难，举步为艰，那说明PTM的设计和准备，没有做到位。而P5P6工程师，虽然摆脱了大量机械的工作，感到无比畅快，但是很快就会感到一丝不安，因为他们有了更多的资源，因此会受到了更大的压力，这种压力主要是思想上的压力，不过这些都是正常的，也是合理的。

　　我想一定会有很多人会对这种分工方式产生疑问，那么这里我先预测一些问题，跟大家解释一下。

　　Q：如果一个project的用例都由PTM写，ta能忙得过来么?

　　A：这就要看用例的规模了，如果按照现在我们的写法，估计够呛，用例写成“说明书”，PTM肯定累半死。用例应该是一个结构化的文档，与知识沉淀珠联璧合，总之这就要看PTM的能力了，怎么设计才能既简洁，又可读。另外如果项目太大(不禁想起WCS)，那估计要多位PTM合作。

　　Q：PTM把用例写好，那执行第一轮测试的时候，他不是没事干了。

　　A：这是因为以前的规定是，用例全部写完，评审完，才能测试，这样其实是不敏捷的，用例的设计和执行本身就可以并行来做，评审只要把关键的测试逻辑评审通过就可以了。开发工程师也是希望我们尽快投入测试，尽快提交bug。另外，测试开始后，PTM还需要不断完善测试方案，特别是测试数据准备方法，PTM要为P4的工作铺平道路，绝对不是甩手掌柜。

　　Q：这样定义，对现有的P4工程师，是不是会感觉不好，好像在说他们只能做简单的执行似的?

　　A：说到这个问题，还请大家保持冷静。对岗位的定义，和对人的要求，是完全不同的，要区别对待。我们设定P4这个岗位，说明团队需要这样的岗位产出，绝对不是说现在这个岗位的工程师只能做这些。对这个岗位感兴趣，适合的人，自然会接受岗位offer。当ta在这个岗位上有了较好的绩效，经常会涉及更高层级的工作时，那么就可以自然晋升了。

　　到这里第二点我们分析完了，下面讲第三点：健康的测试团队中，各个层级的测试工程师比例应该是怎么样的。

　　现在我们的招聘策略是尽量挑选精英工程师，简单来说是至少P6级别，这是非常正确的方针。如果一个团队全是P4P5，在测试技术发展上，必然会遇到难以逾越的鸿沟。那么是不是P6越多越好呢，也未必，试想一个产品线测试团队都是P6，是什么情景。在篮球论坛有人提出这么一个观点，如果由5个科比组成的篮球队，可能战胜不了大联盟的任何一支球队。虽然没办法证明，我认为还是有些道理的。足球队最出风头的是前锋，要是11个都是前锋，也没法踢了。推理到测试团队也是一样，大家自己体会。

　　说到这里想起三国杀游戏，里面分了主公、忠臣、反贼、内奸几个角色，在多人游戏中，这些角色的数量是严格定义的，只有这样设定，各方面势力才能均衡，才好玩，忠臣太多反贼太少，一下就结束了，一点不好玩。并且，当游戏人数发生改变的时候，这些角色的数量也会跟着变，还要遵守一定的规则，保持生态平衡。

　　测试团队也是一个生态圈，各方面势力均衡，工作才好做下去。其实一直以来，“开发测试比”就是开发团队和测试团队保持生态平衡的一个重要指标，这个指标也是讨论最多，大家关注最多的。我认为每个测试团队，也需要确定自己的人员比例，可以根据所对应的Project的特点进行调整。下面假定有一个10人的测试团队，我们按照足球队的阵形，排出了测试人员比例模型，大家参考一下：

　　排下来感觉也挺靠谱的，才发现软件测试和足球还有这么点联系。当然，这只是常规团队的排兵布阵，有一些特殊的project和产品线，是不太合适的，需要重新定义。不过要遵守这个原则，并不是层级越高的人越多越好，而是要各司其职，方能百战不殆。

原文转自：http://www.ltesting.net