本来十一的时候没想发帖的，因为媳妇怀孕了，专心伺候媳妇是第一位的，毕竟鄙人写文字费时太长，并且脑子是单线程运转，干一件事就顾不上其他的了。但是刚才翻论坛看到有个哥们说到了测试团队的考核，里面的内容着实的戳中了我的痛点。他尝试用 bug 数量来考核 QA 的绩效，并且是学习我老东家的模式。。。哎，想一想老东家技术部那恐怖的离职率。我觉得趁着媳妇睡午觉还是写个帖子专门说说吧。今天说的纯属灌水，没啥技术含量。
这貌似是一个永恒的话题，很多人都爱统计 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 管理机制的神奇的公司。过程不表，但是 bug 数目，代码覆盖率，是否开发了什么测试工具，推广到了几条业务线等等貌似都变成了 KPI。我当时的心情是复杂的，因为这些玩意，只要我想糊弄你，真特么的轻轻松松就给你搞定了。用不着一个季度，我一个人撑死一个月就能把一个部门的任务超额完成。反而是线上事故率，trouble shooting 的反应速度等等没人过问没人管了，出了事随便骂几句就拉倒了。貌似大家都盯着那些看得见，摸得着，能带你装逼带你飞的功绩上。
结果是什么呢？ 我就举一个例子吧。我曾经跟我的直属上司因为代码覆盖率的事情吵翻天了。她的理由很简单，QA 得有代码覆盖率，QA 一定要加代码覆盖率统计，QA 必须得掌控代码覆盖率，重要的事情说三遍。我的理由也很简单，特么的除了我和另一个测试架构师以外，这些 QA 里有一个算一个，谁看的懂产品代码？你给一帮从没碰过代码的人统计代码覆盖率有 JB 毛用。不过后来大家应该懂，人家是老大，我得妥协。
再后来的局势就很明朗了，你不是追求 bug 数量么，能用一个 bug 描述的问题我拆成 10 个描述给你看，别笑，我真碰见过这样的，各种看上去高大上但基本没什么卵用的平台也出现了。不过技术部这都还好，市场，销售那边才激烈呢。花公司的钱找第三方公司刷流量，刷数据的都是小场面。我没有在诋毁 KPI 这个机制，一定有公司用的好。只是我没碰见过。
总结
其实我貌似没说怎么考核 QA，恩，对了，因为我也不知道怎么考核。我觉得咱们在公司都是结果导向的，即便可能没发现什么 bug 但只要产品能按质保量的发布，线上没出什么篓子就是合格的吧。恩，我暂时也就这么想了。