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和产品线,是不太合适的,需要重新定义。不过要遵守这个原则,并不是层级越高的人越多越好,而是要各司其职,方能百战不殆。
希望这篇文章,能够帮助大家理清思路,从职业发展的迷雾中走出来,也希望能以这篇文章作为引子,与各位测试经理们继续讨论测试团队的建设模式。最后总结一句话,我希望测试团队向着生态平衡,良性循环的方向前进。
发布评论