2010年底，技术研发部那轰轰烈烈的晋升面试慢慢落下帷幕，有人快乐有人失落。一晃几个月过去了，晋升失败的痛苦慢慢平复，晋升成功的快感也逐渐消退。接下来一个非常实际的问题摆在了我们面前，特别是对那些晋升成功的工程师来说，那就是，晋升成功后，你是不是依然做着相同的工作，跟以前没啥分别。
尽管受到一些争议，新的job model在这次晋升过程中，还是起到了比较关键的作用，它明确的定义了各个层级的测试工程师，应该具备何种能力，能够完成哪些不同难度的工作。除此以外，我们几乎隔一段时间就能看到一幅“测试工程师职业发展路线图”，每张画的都不一样，不过中心思想基本差不多，无非是说测试是万金油，可以向多个方向发展。
关于测试工程师的未来怎么发展，似乎我们已经掌握了足够多的信息了，按理说我们应该拨开迷雾，自信的大步往前走。但是我们却感觉到哪里有点不对劲，并没有体验到轻松畅快的感觉，相反，仍然觉得身在迷宫深处。这些并不正常，我想技术委员会应该做一次回访，针对晋升成功的测试工程师，问问他们的感受，是否感到个人价值倍增，信心百倍，目标明确。
下面只是我的推测，我想回访的结果可能不会那么好，并且很可能会得到相反的答案。虽然晋升成功的感觉很high，薪水也高了，还有同事们那羡慕的眼神，不过这些快乐都是极其短暂的。当大家冷静下来，回到工作岗位时，晋升成功的工程师会发现一个尴尬的现实：他们仍在做着跟以前相同的工作，并没有得到组织授权的，完全不同的任务挑战，也没有新任务委派的动向，一切都那么平静。再看看周围，他们发现了一个更加要命的问题，层级不同的测试工程师，却在做着相似的测试工作。P6在带个项目，P5也在带项目，甚至P4也在带个小项目。
其实真要说区别呢，也不是没有，他们带的项目还是有不同，有的大，有的小，但是看看项目中的具体工作，区别就不是很大了，都要写计划，写一堆用例，一遍一遍的执行，记录一堆bug。这种分工方式看起来合理，责任明确，各管一摊，其实不然，这种分配方法是最简单的，但是很不科学。因为大家都知道，在一个项目的测试工作中，总有一些工作是很简单并且量很大的，而有一些是很复杂但是量却不多，二八原则吧。P6工程师会觉得做那些简单的工作很无趣，而P4工程师会觉得做那些复杂的工作很吃力很累。
我认为这一点，是造成测试工程师对职业发展产生迷惘感觉的最主要原因。P4、P5、P6…每个层级都应该是一个里程碑，当你到达这个里程碑时，将会在各方面有一个很大的突破，而绝对不是周而复始的，不停的在做项目，然后熬很多年，熬成一个组的组长，然后每天处理一堆杂事，最终迷失自我。这绝对不是我们该走的路。
上学时学过，人类进化的一个关键，是社会大分工，每个组织负责不同类型的工作，精益求精，不断进化。测试工程师的工作如何分工，和job model产生了必然的联系。job model需要完成3个层次的定义：1、各层级测试工程师的能力定义。这个已经完成了，这里我们不再多说；2、各层级测试工程师需要完成哪些类型的工作。这个其实现在的model并没有说清楚，所以大家在工作中会感觉到有些迷惑，不过根据现有的job model倒是可以推理出来，后面我会总结一下；3、一个健康的测试团队，各个层级的测试工程师的比例。这个完全没有定义，所以我们马上会重点分析。
先讲第二点。真正合理的测试工程师分工，我想应该不是P5负责A项目，P6负责B项目，也不是在一个项目里，你负责甲模块，我负责乙模块，当然更不能是，测试负责人把模块平均分给几个人，然后自己负责所谓“沟通协调”的工作。不同层级的测试工程师，他们的分工应该按照工作类型来分。我们看下面的表格：
| 测试工程师层级 | 负责工作内容 |
| P4 | 1.根据需求文档和测试文档掌握测试策略 2.执行大部分的较简单的TC 3.记录bug 4.完成project的简单日常测试 |
| P5＝PTM | 1.制定project测试计划 2.完成所有TC的设计，包括设计测试准备工作方案 3.执行project中较复杂、较核心的TC 4.记录bug，控制bug健康度 5.为project编写知识沉淀和培训文档，方便P4工程师快速上手 6.对project质量薄弱点进行控制，减少线上bug数量 |
| P6 | 1.根据project业务特点和架构特点，设计更科学的测试策略 2.帮助PTM提高测试效率（多方面的） 3.解决project中特别棘手的技术问题 |
| P7 | 1.工作内容与P6几乎一样 2.解决问题的方式必须更科学，适用更多project 3.需要联合开发团队和其他测试团队共同处理问题 |
这里我们明确一个概念，就是项目（Project），在新twork中，项目的概念变大了，购物车、收藏夹这些都是项目，而购物车2.0、收藏夹3.0这些是演进的一些版本。因此，PTM（Project Test Manager）有了新的含义，其实就是之前所说的“子产品的owner”，但是这样叫太拗口，干脆以后统一叫PTM。注意，P4工程师的责任范围内，是没有PTM的责任的。
好，下面我们继续讲不同层级的分工。上面从工作内容上进行了分类，下面我们从他们所提交的bug，来进行一下分类，请看表格：
| 测试工程师层级 | 发现的bug |
| 开发工程师 | 80％初级bug 初级bug只要开发简单自测一下，就可以发现，如果由测试发现，记录、修复、验证、沟通，极大浪费了项目人力资源 |
| P4 | 20％初级bug 80％中级bug P4工程师覆盖的测试用例，都是逻辑清晰明了的，比较容易判定的，因此发现的bug，大部分是中级bug |
| P5＝PTM | 20％中级bug 高级bug PTM需要覆盖project中最复杂的逻辑，并且要花很多时间进行探索性测试，因此发现的bug，大部分是高级bug |
| P6 | 你们自己看着办 |
| P7 | 你们自己看着办 |
从提交的bug质量上，很容易看出一位工程师的技术和能力，如果P6发现的bug，跟P4差不多，那怎么好意思继续混下去。下面我们再从另一个维度来比较，那就是：是否专注在一个project里面，请看表格：
| 测试工程师层级 | 对Project专注程度 |
| P4 | 可以在几个Project中轮回 |
| P5＝PTM | 必须坚守自己的Project |
| P6 | 可以选择坚守一个Project，也可以不限定Project |
| P7 | 完全不限定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人的测试团队，我们按照足球队的阵形，排出了测试人员比例模型，大家参考一下：
| 比例模型 | 不同层级的人数 |
| 5-3-2 | 5*P4 3*P5 2*P6 |
| 4-4-2 | 4*P4 4*P5 2*P6 |
| 4-2-3-1 | 4*P4 3*P5 2*P6 1*P7 |
排下来感觉也挺靠谱的，才发现软件测试和足球还有这么点联系。当然，这只是常规团队的排兵布阵，有一些特殊的project和产品线，是不太合适的，需要重新定义。不过要遵守这个原则，并不是层级越高的人越多越好，而是要各司其职，方能百战不殆。
希望这篇文章，能够帮助大家理清思路，从职业发展的迷雾中走出来，也希望能以这篇文章作为引子，与各位测试经理们继续讨论测试团队的建设模式。最后总结一句话，我希望测试团队向着生态平衡，良性循环的方向前进。