灌水 我也聊聊测试团队的考核吧

孙高飞 · October 05, 2016 · Last by Kai Rong replied at July 05, 2018 · 6084 hits

前言

本来十一的时候没想发帖的,因为媳妇怀孕了,专心伺候媳妇是第一位的,毕竟鄙人写文字费时太长,并且脑子是单线程运转,干一件事就顾不上其他的了。但是刚才翻论坛看到有个哥们说到了测试团队的考核,里面的内容着实的戳中了我的痛点。他尝试用bug数量来考核QA的绩效,并且是学习我老东家的模式。。。哎,想一想老东家技术部那恐怖的离职率。我觉得趁着媳妇睡午觉还是写个帖子专门说说吧。今天说的纯属灌水,没啥技术含量。

关于bug数

这貌似是一个永恒的话题,很多人都爱统计bug的数目并以此来评判一个QA是否称职。QA发现的bug多了就说他是个好QA,发现的少就说他不努力或者业务不行。其实这是一个悖论,QA的职责是保证产品的质量,而bug过多则证明了产品质量差而不是产品质量好。 所以我挺纳闷那些测试大佬们总追求bug数量干什么,这是希望产品质量好啊,还是差啊。你们难道不应该追求线上无bug么?我是不太清楚这种扭曲的价值观当初是怎么在QA圈子里流行起来的,但我很清楚有这么扭曲的价值观的QA团队一定是失败的,也是可笑的。

我说说我是怎么看待bug数量的吧。如果在测试中发现bug过多,第一个反应是这么多的bug会不会影响发布?这些bug中有多少是可以忍受直接带上线的,有多少是不可妥协一定要修的?跟当前的排期对比一下,还有多少feature没开发完?剩下多少时间修bug?这么多bug修完了有没有时间重新验收了?总结完所有风险就该找上产品和开发聊聊了,咱们该进小黑屋的进小黑屋,该加班的加班,该砍需求的砍需求。那么我们说下一步,第一反应是评估发布风险,第二反应就是思考为什么有这么多bug,我们的流程有没有问题?RD的UT够不够?需求的评审到位不到位?每日的CI有没有效果?之前用例的设计全不全面?当前产品的架构有没有问题?等等等等,这方面的事情我在上一篇文章测试开发之路--QA 的能力中总结过了。如果团队有良好的流程和质量保证意识,再加上合理的工具和自动化,是不会在测试中发现这么多bug的。bug多了证明团队当前是有问题的,证明QA在一定程度上没有做到位,证明当前的产品是有风险的,反正bug过多肯定不是啥好事。所以一看到QA发现的bug多就高兴的老大们,你们到底咋想的呢?

关于KPI

说到考核一定避不开KPI,KPI是个神奇的东西,有无数人趋之若鹜,也有无数人弃之如敝履。我的老东家是一个成立不到一年就引入KPI管理机制的神奇的公司。过程不表,但是bug数目,代码覆盖率,是否开发了什么测试工具,推广到了几条业务线等等貌似都变成了KPI。我当时的心情是复杂的,因为这些玩意,只要我想糊弄你,真特么的轻轻松松就给你搞定了。用不着一个季度,我一个人撑死一个月就能把一个部门的任务超额完成。反而是线上事故率,trouble shooting的反应速度等等没人过问没人管了,出了事随便骂几句就拉倒了。貌似大家都盯着那些看得见,摸得着,能带你装逼带你飞的功绩上。

结果是什么呢? 我就举一个例子吧。我曾经跟我的直属上司因为代码覆盖率的事情吵翻天了。她的理由很简单,QA得有代码覆盖率,QA一定要加代码覆盖率统计,QA必须得掌控代码覆盖率,重要的事情说三遍。我的理由也很简单,特么的除了我和另一个测试架构师以外,这些QA里有一个算一个,谁看的懂产品代码?你给一帮从没碰过代码的人统计代码覆盖率有JB毛用。不过后来大家应该懂,人家是老大,我得妥协。

再后来的局势就很明朗了,你不是追求bug数量么,能用一个bug描述的问题我拆成10个描述给你看,别笑,我真碰见过这样的,各种看上去高大上但基本没什么卵用的平台也出现了。不过技术部这都还好,市场,销售那边才激烈呢。花公司的钱找第三方公司刷流量,刷数据的都是小场面。我没有在诋毁KPI这个机制,一定有公司用的好。只是我没碰见过。

总结
其实我貌似没说怎么考核QA,恩,对了,因为我也不知道怎么考核。我觉得咱们在公司都是结果导向的,即便可能没发现什么bug但只要产品能按质保量的发布,线上没出什么篓子就是合格的吧。恩,我暂时也就这么想了。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 26 条回复 时间 点赞

首先不评论你的老东家了,家家有本难念的经。
很高兴我的想法让你产生了共鸣,说说我的痛点:每个月的24号是为每个团队成员填写考核的日子,对我来说绝对是一件痛苦的事情,当前的状态是能加尽量加,毕竟都看到大家都这么幸苦,我通常会为其加考核有几个原因:
1、这个月经常加班完成了紧急的测试项目;
2、完成了安排的测试工具开发任务,考核至少1.2;
3、能够利用晚上加班时间进行充电,例如阅读测试相关的书籍,和测试团队的其他成员分享自己的测试经验;
4、这个月测试的工作量,高效完成安排的测试任务的同时,主动协助其他模块进行版本测试;
5、主动进行测试工具开发并运用到产品测试过程中,考核至少1.3;
6、主动项目总结、主动发现测试团队中的问题,分为:

  • 发现问题
  • 发现问题,提供解决方案
  • 发现问题,提供解决方案,尝试解决
  • 发现问题,提供解决方案,尝试解决,效果反馈

自我认为这些都是比较不好量化的,完全凭借的是主观感受,对测试团队成员可能不太公平。

为此我考虑了BUG数(不考虑具体的版本数量)作为其中的一个考核指标,这是一个可以量化的过程,规则很容易定,最重要的还是要进行过程管控,作为测试团队的leader,在施行阶段要对BUG进行查阅,对团队成员提出的BUG进行评估,这也能很好的评估开发团队的产品质量:

针对测试:

1、让团队成员有一种目标感,能够知道自己离目标还有多远,会尽可能的发现产品中的BUG,这是正向的。
2、目标完不成,说明你发现不了问题,能一定程度说明你在用例设计或者测试过程做的不够好,你该在这方面提升了。
3、每次都能完成的,这个说明你有独到的方法和发现问题的眼睛,你该和你的测试团队分享你的经验了。

针对开发:

1、BUG数可以进行排名,一看就知道哪个开发团队的产品质量如何,对开发是有一定约束力和推动力的。

不知道大家是用什么方式来考核测试团队成员的,说的再多,还不多先做了再说,我将会在Q4阶段进行尝试,先会和我的测试骨干进行商量这个事情,大家认可后就开始开干,到时候再和大家分享我的实际效果。

#1楼 @aizaimenghuangu
首先很感谢你码了这么多字来回应这篇帖子,我分4点来说一下我的感受吧。

  1. 真的劝你一句,千万别用bug数量来考核QA,原因我帖子里说过,过于专注于bug数量也很容易忽略流程上的,机制上的,工具上的东西。而且也容易因为bug数量的问题跟开发团队造成矛盾。

  2. 我理解你的痛点,我曾经也为这些痛苦过。但后来我把这些考核都抛弃了,只要产品上线没什么问题就可以。这个是实的,其他都是虚的。即便发现了一万个bug,如果线上还是出问题那又有什么用呢。

  3. 就像你说的,我们是以结果为导向的,那么线上质量就是结果。中间大家加了多少班,利用业余时间学习了多少,分享了多少经验为什么要列入考核呢?如果这些都变成KPI了,那么结果我几乎可以肯定是,大家尽量加班耗时间,营造一种很忙,很爱学习的样子。动不动就开什么技术分享会来分享一下装个B也是很常见的。时间长了只会培养出了一个很不好的气氛而已。我们的文化以加班为耻,能不加班就不加班。逼着大家把效率提升上来,逼着大家把自动化做起来。所以我不太理解你费尽心思营造一个加班的团队文化是为什么?

  4. 产品质量不是QA一个团队的事情,感觉你的眼界太局限于QA团队个体了。应该多想想怎么协同其他部门,定制标准,规范流程。如果某一天你发现RD提测以后测试出的bug特别少。那时候QA团队才是成功的

bug 数来考核?是80年代的国企么?

#2楼 @ycwdaaaa 嗯 认可。
1、不拿BUG数来考核QA,但是应该作为开发团队产品质量的参考,毕竟BUG数量增加了测试的工作量。
2、我现在的考核标准是:线上产品问题数量作为测试团队成员的考核。
3、内心还是很推崇加班文化的,直到公司实行了强制的996,原来加班是为了充电,现在变成强制性的了,效果可想而知。
4、是的,目前公司的很多规范都是我们测试制定和推动。

关于加班文化,这里多说一句:我的初衷是以创业团队的方式带领测试团队,不管怎么样,带着团队拼一把。

#3楼 @testly BUG数作为开发产品质量的考核参考。

#5楼 @aizaimenghuangu 如果是以bug数为考核标准,那就是感觉对自身的产品有足够的信心咯?
如果是这种“大家一起来找茬”模式,找到一个多少钱的这种模式,我是认可的!

  • 感觉在考核和评估团队成员这个事情上确实要有自己的一套体系,不管是从结果导向以线上质量为主,还是平时在项目进度控制以及开发质量保证上,这些都是方法。
  • KPI不过只是将其正规化让大家都知道并让大家去跟着做,其实初衷是好的,不过凡事涉及到利益相关的自然不可避免都会产生一定的质变和偏差,这个东西做得好可以很好的激励大家,提高团队效率和产品质量,做的不好自然就是各种为了KPI而KPI。
  • 回归到测试这个职位本质来看终究还是保证好产品质量,关键还是人,团队人都为产品考虑,都想着怎样提高产品质量,方法嘛也是自己人在项目中摸索出来的,所以培养团队氛围和团队成员我认为才更重要。
  • 至于加班文化反正我是没有好感,让大家都以加班为荣并且还欣然接受,除了像华为那样用福利和待遇去砸,一般公司我觉得还是难的,毕竟不是人人都是上进有为青年,只想着学好做好做贡献的,带人现实点还是好的。以上纯属个人看法😄

#5楼 @aizaimenghuangu 这个也要看业务的,有些业务出错率高,有些低。
然而你直接用bug数量量化,导致敢承担责任的开发反而得到不公平的待遇啊。

说说我们公司目前的考核方法

我们公司目前还是已黑盒为主,还没有引入自动化测试这些东西,一方面是人员水平普遍不够,另一方面是我们部门还要同时负责技术支持,每个人的工作量都挺大的没什么时间搞(其实就是懒...)

考核的几个方面

  1. 需求覆盖率
  2. 用例执行率
  3. 用例有效率
  4. 缺陷验证及时性
  5. 线上BUG数

实际的考核方式就是通过自己开发的一套系统,从需求到测试所有的数据都在里面,然后进行计算,完全已数据为准,计算完成后领导们会根据实际的任务量和工作压力等等平衡一些主观分数,但调整的范围都比较小。
目前感觉这套KPI的考核方式仅从考核项来讲还是有一定的评估能力,比BUG数还是高明了不少,但是实际的KPI计算方法我就不想多说什么,因为计算这个数据的系统是我们部门自己写的,所以针对测试人员的KPI考核你们懂的...

以BUG数量来作为考核的话,只会起反作用,也是最low的管理理念。

以上回答都有一个共性,就是断定如果以bug数量驱动,测试会乱报bug。

另外也没有提到一点,测试人员的素质和职业操守。职业操守低的同学什么标准都是没用的。

我并不觉得bug数量为kpi有什么不妥的。一个产品放在一个测试团队面前,只有几个bug,上线后一堆问题,谁会觉得测试阶段发现bug数量少是好事?不要提什么流程,理想化的东西都落不了地,落地了也是走样。

如果以bug数量为kpi,必须还加上质量。开发不是任测试宰割的小羊羔,低质量的bug,投诉没有二话。

以管理为目的而不是项目质量为目的进行的考核,都是呵呵的。KPI应该引导公司价值观导向,应该是一个合适周期根据实际情况变化的。单独的测试团队考核BUG数没什么意义,而和开发一起考核,又容易陷入无休止的“这个问题是不是BUG”的争执。至于大家干的都差不多,非要考个优良中差的公司,😈

以bug来考核比较扯淡,这应该是大家的共识(最起码是战斗在一线的tester)

单纯的以结果来考核,如线上bug数等,也不会公平
有的团队的产品活跃用户过亿,有的才百万级别
你用绝对数量来对比,显然有失公平

非常认可 @seveniruby 的观点
对测试的考核应该是多个维度的
而且这些数据不应该是死板的,也不是孤立存在的

以bug数量来考核测试人员是上头人能想到的最直接的考核方式了,说用bug数量作为考核的已经将测试工作划分到生产劳动中了,比如生产线也是考核产量,部分开发也是看代码行数的。但是测试工作也用这个考核方法不适用。
真的做测试了就会发现,测试还不同于生产,而且有一部分属于服务行业了,还有追踪、反馈、各类文档等等工作,绝非单纯的像领导们说的“产出bug”。连坛子里这些懂测试的人都没能说出个所以然,所以测试考核真的很难定论。
目前我的团队的绩效考核方法是:想要团队成员做的工作都体现在基本考核中,我期待他们做的工作都在加分项中。
说实在的,工作做好是最重要的。

#9楼 @seveniruby 没有漏测是很多质量团队首要目标,互联网公司的质量保证归根结底是又好又快的实现版本的发布,不同的行业不同的阶段对bug要求也不应该是一样的。对新人来说,熟悉业务的阶段,发现bug多少确实可以是一个考核标准,当已经成为业务熟手以后很难说还有什么用处。相反的,以前听过某个通讯行业公司的分享,不光通过bug考核QA也同样的考核开发,而且双方的KPI是背道而驰鼓励对立的,提bug的行为被称为上甘岭,双方反复争夺,这样去倒推开发去提高自己的代码质量,测试去尽最大可能的发现验证代码质量。

#17楼 @cobbxia 通讯行业已经稳定了 需要这样。每个行业发展的阶段主旨并不一样。追求稳定这样做没错,追求速度就得放下这个,互联网公司多已经不用这个了。只做为辅助参考目标。

关键还是看清楚自己的公司性质,自己队伍是怎么样的情况。

我是超级讨厌用bug数量来考核QA的,上家公司才干了4个月,尼玛走人的原因就SB组长说我提交的bug数量偏少,尼玛四个月提交了230个bug还被嫌弃少。

整体是赞同的,但是不太理解里面说的“漏测率”,此处的漏测率大体是怎么定义的呢?我理解的是线上的bug数与(线下+线上bug数)之比,但这里又用到了线下bug数,当测试人员提交的bug数很高时就拉低了漏测率,当提交的教少时漏测率就上去了,为了达到低漏测率就又跟统计bug数作为QA kpi是一个路数了。

孙高飞 回复

特别赞同您的观点,人性而又高效率

这个问题与所属的行业,公司,团队成员素质都有关系。
比如,由于待遇没有竞争力找来被动工作的人,也不主动学习和改进,那么既要完成项目的总体目标,引入这种机械式的考核标准,可能比较合适了,看得见,摸得着,易量化,为了弥补不足,可以定期轮换项目等等,当然,总体上肯定是比较低效了。
我所在的公司测试人员较少,一个人负责多个功能或小产品,是典型的敏捷开发,发布周期也很短,saas模式,所以呢,对质量还是很重视的,因为质量问题很快就会暴露出来,且引发赔钱等坏的影响。
招人阶段标准要高,比如基础的编码能力,学习能力,和别的角色的配合能力等,好多轮的面试,结果就筛选出来一些技术不弱,乐于合作,积极主动,兼顾业务和技术的同学,负责相关产品的一系列测试,功能,自动化,接口,集成,性能,也负责一些ticket的处理。
说了这么多,我们的kpi或考核怎么做的?
我们定了一些公司级别的核心能力指标,比如团队协作很好,比如重视客户体验,比如技术上的领先,比如。。。
然后,你自己挨个列举事实,把自己在该领域的成长,事迹写上去,再打个分,等级。
而最后,这个结果,要经过直属经理,和其他接口部门的领导一起review.
最后再汇总一个总的绩效等级。也就几个等级而已。
说了这么多,就是比较宽泛,而根据各个合作组的整体印象或对事实的评价来打分,不看太具体的数据。
公司较小,所以没什么混的人,你干得好坏,是否得力,大家都知道。
负面的:如果你负责的项目线上经常出问题,那肯定是备受瞩目的。

我遇到过一个项目,测试经理以每天跑的case数,报的和验的bug数来定工作量, 弊端很多

wuvru01 回复

很赞同你的方法,对公司人员较少,业务使用量不大,从考核成本效率和考核公平性上说,非常适合

测试环境测试出来的bug数量,是用来考核开发团队的代码质量的。
生产环境发现的bug 数量,是用来考核测试团队的测试质量的。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up