测试管理 KPI KPI KPI 头疼的事情说三次。一起吐槽吧!

xiaoxin · October 04, 2015 · Last by K米测试 replied at January 12, 2017 · 3161 hits

想了解一下各位互联网公司,测试人员的KPI现状。
大家觉得哪些需要吐糟, 怎样更合理呢?
特别是测试开发的考核,没有头绪。

目前在构建一个小测试团队。希望不为了KPI而KPI。
真正的为提高工作的效率而考核, 也为团队成员的职业发展负责。

谢谢!

共收到 27 条回复 时间 点赞

kpi 是一个比较好的管理方法。

kpi关键是怎么定。kpi必须有

了解你团队的目标, 你团队的KPI要和更高的领导确定. 确认方向.
然后是把KPI化解到每个人. 不用太确定细节的数字. 不然就会陷入官僚式的数字魔窟. 覆盖率在69%和70%并没有差别. 不必纠结.

KPI要从结果和过程中分别体现出来.
结果就是产品的质量数据. bug率. 线上故障, 用户投诉, 迭代或者发布次数.
过程就是测试的效率, 人力成本, 需求满足度, 测试覆盖度, 技术应用度, 然后再细化具体的数据就行了
比如测试多少轮, 测试发现多少bug. 测试时间缩短多少, 技术的价值体现, 测试体系的完备和流程规范. 人员的成长等

4Floor has been deleted

#2楼 @monkey 我这是新公司嘛..一般先参考下一线互联网的经验,然后慢慢探索修改。 请教下上海支付宝比较看重什么呢?

#3楼 @seveniruby 多谢提供思路。 我从传统IT出来,对互联网公司的相关还是了解不多。

#1楼 @lihuazhang 那更好的办法是?

#7楼 @xiaoxin okr吧。学习谷歌的。但是不要严格执行,小公司或者新公司其实没必要用 kpi 来衡量。

9Floor has been deleted
10Floor has been deleted

我这现在就没有,现在有个问题很恶心,只要线上出了问题,立马就问责了,测试为什么没有注意到这个地方等等,然后惩罚。。显而易见的状况是,需求也早提出来了,大家都讨论过了,感觉需求没有问题,开发也给了充足的时间了,测试也给了充足时间测试了,可还是出问题了,大家一直在想问题出在哪,然后结果就是大家认为问题出在测试方面。我的想法是从测试覆盖程度入手,就是看测试用例的覆盖程度,测试用例的执行程度和测试的周期时间。

#11楼 @face_south

显而易见的状况是,需求也早提出来了,大家都讨论过了,感觉需求没有问题,开发也给了充足的时间了,测试也给了充足时间测试了,可还是出问题了

靠测试是避免不了线上问题的。真实环境是你永远没有办法模拟的。再说了,哪个东西没bug?所以要看线上问题是那种问题,是不是主路径,是不是容易发现,是不是兼容性?比如主路径问题,那测试就应该问责了。如果是兼容性,那就只能下次注意。

xiaoxin #13 · October 08, 2015 作者

#8楼 @lihuazhang 多谢提供思路。对于测试开发,或者架构师有没有比较合理的衡量项目?

xiaoxin #14 · October 08, 2015 作者

#11楼 @face_south 测试难免会背些黑锅...唉

@lihuazhang 是这样,发现的情况是,主路径线上也有问题,但是测试环境就可以,也在找具体是什么问题;还有就是一些小的地方,这个主要是测试没有覆盖到,要想办法避免;兼容性的一些问题,只要老板看到了就没得说了,等骂,老板不管什么原因。。

#15楼 @face_south 都一样。。这就是咱们这行的杯具
我上一家老板就是因为这个干掉了我。。。

先明确原因. 如果是环境的差异, 就逼研发提供一个隔离环境满足测试, 否则就说服他们担责.
在很多公司里面, 出了问题首先是研发的责任, 这样是逼他们提升自己的产品质量. 质量是开发出来的, 测试偏防御.

梳理你们出的所有问题, 然后提出改进建议, 理清需要支持的资源, 然后再明确是谁担责, 在公司树立一个有问题研发先担责的氛围, 这样你们压力就会小些. 也符合利益. 我想cto和ceo会同意的

有KPI,基本都是接近满分,感觉就是纯粹为了那点奖金~很纯粹,说是14薪,然后只发12薪,另外2薪发奖金,有多蛋疼,大家都懂的。。。

19Floor has been deleted

目标管理中,有一个SMART原则(Specific、Measurable、Attainable、Relevant、Time-based),即使是为了提高工作的效率而考核,那如何把提高效率量化也是一门艺术。 通常老板们都是结果导向,在某个特定时间段内能提供什么样的数据给。我们可以提供哪些数据呢,测试阶段发现bug数,上线后bug漏测数,用户投诉数,app崩溃率,发布次数,测试覆盖率,其他团队反馈,两个版本横向对比对应数据等。至于我们如何实现这个数据的,是通过流程优化,技术改造,还是短时间赶工,其实他们真心不care。

至于测试背锅,好的质量一定是设计出来的,不是测试出来的,测试不过是最后一道门而已。不过谁让咱们是最后一道门呢,没有背过锅的测试不是好测试。我们能提前做的就是短期分析问题产生的根源,有什么改进措施,实施改进措施,追踪改进措施的效果;长期而言更早的介入,关注流程,规范流程。

特别是当一个测试团队构建的时候,内部和外部必然摩擦不断,这个时候一定要做好跟上级的沟通,了解他的期望。这个不是投机,而是确认我们提供的是他想要的。

#20楼 @tom_ma 说句不好听的话,开发和测试应该配合起来骗老板。

#20楼 @tom_ma 额。。。这个都太空,实际的过程中,落地的时候都是看人,无论上面还是下面

#22楼 @monkey 确实,核心岗位的人决定一个团队的整个气氛。

#21楼 @lihuazhang 😄 恒温为何老是这么幽默~~

#11楼 @face_south 上线出问题频率高吗?

#24楼 @tom_ma 主要是很多老板不懂技术,会瞎指挥。

kpi只是一把尺子,就看怎么去量,主要团队中的人要以做好一个产品为出发点,这样才能提高产品质量,至于kpi就是领导的事了。

最近也在为KPI而烦恼,觉得确实不应该从数据出发,应该从产出来关注。谢谢提醒。
#3楼 @seveniruby

#15楼 @face_south
预发布环境模拟线上环境应该可以解决和测试环境不同的问题。
至于各方面的覆盖问题应该和需求方多沟通,明确责任认定。至少用例评审是对测试的一种保护。

好久的帖子,看到KPI 忍不住想要留个言,说一下我个人的经历。三年前团队初建的时候,准确的来说是一个思想上"新老交替"的时期,我是极力想要推出一些更简易的考核机制的,想要放弃之前工作传承下来的KPI机制.当时也刚刚开始搞管理,接触到OKR,公司还专门找了创新工场的人来讲OKR。起初是觉得OKR 是一个好的机会,可以摆脱KPI的条条框框,刚开始大刀阔斧(创新工场的那位说是KPI和OKR不能共存),开始定义"有野心的"、“有挑战的”各种月目标、季度目标、年度目标,实行了半年,发现OKR并没有带来多大的改善,自己检讨了一下,主要有几个原因:
1.公司大环境,公司有没有自上而下在推动OKR
2.成员的实际认知,大家对于OKR有没有充分认知、是否认可OKR
3.新建立的部门是否合适这样宽松放养式的考核制度.
那段时间想了很多,最后还是回去做了改良KPI的动作(为了改善产品品质测试、提交问题,而不是为了KPI 数据测试、提交问题),最终的考核变成了:有数据支撑的KPI + 测试技术拓展的OKR 现在用着觉得还不错.
ps: OKR里面有两项,个人觉得不错
1.daily report(简单几句话总结当天的工作和所得)
2.全透明的目标管理(全员都清晰了解,上级、下级的近期目标和瓶颈)

以下参考网络,有一定的参考价值:

产品测试方面的关键绩效指标KPI可分为两类:
一类是测试质量类指标,反映测试工作的质量,可促进提升测试能力的水平。
另一类是测试效率类的指标,用于促进提升测试的工作效率。常见的产品测试质量类的KPI如下:

1、产品设计缺陷率:产品经过测试、小批量试制验证以后,在批量生产和用户使用过程中发现的产品设计缺陷次数,与已生产、发运的产品台数之比,单位是次/台(或次/台.季度)理想情况下,已通过了测试和验证的量产产品应该没有设计缺陷,但是实际测试工作中不可能发现全部设计缺陷。计算本指标时,可以扣除那些测试已发现、但设计部门未予以修改的设计缺陷。本指标属于测试质量类指标,用于促进提升测试能力和水平。

2、产品缺陷漏测率:类似的指标还有因设计缺陷导致的产品(和部件)返修率、产品漏测率。所谓产品漏测率,是指产品在生产、用户使用等环节发现的漏测问题数与产品问题总数之比。

3、测试覆盖率:测试项目、测试用例对产品需求规格的覆盖率,或者对产品硬件设计的功能点覆盖率,或者对软件代码的覆盖率等等,这类指标用于衡量测试的充分性。

常见的产品测试效率类指标如下:

1、 人均发现问题数:每名测试工程师每天(或每月)在测试工作中发现的产品问题或缺陷个数的平均值。本指标可用于评估测试工程师数量是否合理。

2、 自动化测试比例:能够实施自动化测试的测试项目(或测试用例)个数与总测试项目(或测试用例)个数之比。本指标用于促进提升自动化测试水平。

3、 测试项目(或测试用例)的问题发现效率:单个测试项目(或测试用例)发现的问题数量的评均值。本指标用于促进提升测试项目(或测试用例)的有效性。

这几天也是一直在思考这个问题,希望有一些可以落地的内容。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up