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

　　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项目，也不是在一个项目里，你负责甲模块，我负责乙模块，当然更不能是，测试负责人把模块平均分给几个人，然后自己负责所谓“沟通协调”的工作。不同层级的测试工程师，他们的分工应该按照工作类型来分。我们看下面的表格：

　　这里我们明确一个概念，就是项目(Project)，在新twork中，项目的概念变大了，购物车、收藏夹这些都是项目，而购物车2.0、收藏夹3.0这些是演进的一些版本。因此，PTM(Project Test Manager)有了新的含义，其实就是之前所说的“子产品的owner”，但是这样叫太拗口，干脆以后统一叫PTM。注意，P4工程师的责任范围内，是没有PTM的责任的。

　　好，下面我们继续讲不同层级的分工。上面从工作内容上进行了分类，下面我们从他们所提交的bug，来进行一下分类，请看表格：

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