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

前言

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

,