测试之家

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

孙高飞 · 2016年10月05日 · 最后由 Kai Rong 回复于 2018年07月05日 · 8582 次阅读

前言

本来十一的时候没想发帖的，因为媳妇怀孕了，专心伺候媳妇是第一位的，毕竟鄙人写文字费时太长，并且脑子是单线程运转，干一件事就顾不上其他的了。但是刚才翻论坛看到有个哥们说到了测试团队的考核，里面的内容着实的戳中了我的痛点。他尝试用 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 但只要产品能按质保量的发布，线上没出什么篓子就是合格的吧。恩，我暂时也就这么想了。

37 个赞
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
打赏支持
共收到 26 条回复 时间 点赞
K米测试 #1 · 2016年10月05日 4 个赞

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

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

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

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

针对测试：

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

针对开发：

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

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

testly #3 · 2016年10月05日

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

K米测试 #9 · 2016年10月05日 1 个赞

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

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

K米测试 #5 · 2016年10月05日

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

testly #6 · 2016年10月05日

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

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

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

Donald Yang #10 · 2016年10月09日

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

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

考核的几个方面

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

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

JasonChiang #11 · 2016年10月09日

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

恒温 #12 · 2016年10月10日 2 个赞

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

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

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

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

hellomike #13 · 2016年10月10日

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

CaliforniaDream #15 · 2016年10月11日 1 个赞

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

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

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

linda #16 · 2016年11月28日

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

夏日鸣虫 #17 · 2016年12月12日 1 个赞

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

思寒_seveniruby #18 · 2016年12月12日

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

garfield #19 · 2016年12月30日 1 个赞

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

cicy #21 · 2017年03月13日
对 思寒_seveniruby 回复

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

milly #22 · 2017年04月01日
对 孙高飞 回复

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

WILL #23 · 2017年08月30日

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

yandy #24 · 2018年05月03日

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

OBJ #25 · 2018年05月16日
对 WILL 回复

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

Kai Rong #26 · 2018年07月05日 1 个赞

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

ABEE 在 ycwdaaaa (孙高飞) 在 TesterHome 的发帖整理 中提及了此贴 01月12日 13:47
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册。