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

乐哈哈yoyo

前言

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

巴黎的灯光下

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

草帽路飞UU

需求覆盖率
用例执行率
用例有效率
缺陷验证及时性
线上BUG数

小皮球的故事

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

千里

知识型工作，并不好考核