1. STest软件测试社区首页
  2. 测试经验

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

前言

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

,


29 个赞
举报

原创文章,作者:测试通,如若转载,请注明出处:http://www.stest.com

发表评论

电子邮件地址不会被公开。 必填项已用*标注

QR code