测试人员的KPI,这个梗究竟如何破?

Test Ninja 软件质量报道 2019-01-31

在 从PDD薅羊毛事件想到DevOps那些事 文章中有一同学留言:

“关于测试人员的KPI这块,这在行业上一直都是个梗,难解...”, 

的确感到这是一个问题,答应为此写篇文章来回答这个问题。


测试人员的KPI是一硬梗,

似乎无解,就像软件工程没有银弹

感觉自己没必要掉进这个坑里;

测试人员的KPI也要取决每个公司:

如何看待测试、测试人员

有上下文,case by case;

如果真正想破掉这个梗,

需要走进企业,深入调查分析

了解公司想要什么,就选择衡量什么;

而且需要系统地定义度量体系,

如同我《全程软件测试(第3版)》,

在第14.2小节,用了14页来介绍测试过程的度量指标。

KPI是一把双刃剑

定义了正确的KPI,能够提高大家的工作效率

定义错误的KPI,就会有错误的导向作用,

成也KPI,败也KPI,

甚至有人说,正是KPI毁了Sony。

所以不少优秀公司选了OKR(目标与关键成果法)

废话少说,进入正题。

KPI 是Key Performance Indicator的缩写,即关键绩效指标,

用于衡量或管理员工绩效的工具,

并与公司的战略目标挂钩、联系起来。

如果将KPI用于软件测试人员的绩效衡量,自然会取决于:

  • 特定的公司所定义的关键商业目标;

  • 其对质量的认识,特别是对“质量起什么作用”的认识;

  • 对软件测试的态度、理解的程度

所以,不同的公司对测试人员绩效考核的KPI自然不一样,

仅仅看到用例数或缺陷数肯定是片面的,

仅仅看到测试自动化成果也是片面的。

真正有优秀的质量文化的公司可能不需要针对测试人员的特定KPI,

而是针对整个研发团队设立KPI

而没有良好的质量文化的公司即使实施了质量相关的KPI,

也不一定有良好的效果

在这篇文章后面的另一段留言,让人印象深刻,算是佐证

“经常在想,一个做质量相关工作的人本身的所做所为却没有质量可言,真是有点讽刺。还在注重需求分析,认真做测试设计的人其实离本质最近。但是这么做却没有一点现实层面的好处。唯有一种良知,一种自我价值的实现,一种理想主义在苦苦支撑。也许无数次想投奔另一个阵营,但始终没有说服自己。”

注重需求分析、认真做测试设计的人其实离本质最近,

应该会带来良好的效果,能被衡量出来,

即使这种衡量不是直接的。


如果真要用KPI衡量测试人员的绩效,如何定义呢?

可以不考虑那些通用的KPI指标,如:

发扬公司企业文化、创造价值、创新、

协作、知识分享、提升团队凝聚力、

培养新人、服务客户、个人发展潜力等等

而只考虑测试工作自身的数量、质量和效率

暂时也不考虑权重、优先级等,

毕竟那是一个系统的工程,需要几个月的时间才能做出来。

这里只能偷懒,简单列出度量的指标,让你们各取所需。

而且如果真正这样去衡量测试人员的KPI,

那些实实在在做事的人不会被委屈,而是能得到肯定。


1. 测试的质量

  • 客户满意度

  • 上线后出现的缺陷数所占比例(按级别)

  • 所设计的测试(用例)的覆盖率(看做了什么类型的测试、对覆盖率的理解和要求)

  • 需求、设计评审漏掉的问题或比例

  • 无效用例/脚本百分比

  • 用例或脚本执行的稳定性

  • 被拒绝或延期的缺陷(误报)百分比

  • 重复的错误

  • 违背流程或规范的次数

  • 质量改进速度


2. 测试的数量

  • 评审了多少需求(文档、用户故事)

  • 测试覆盖了多少需求点

  • 评审了多少设计

  • 评审了多少代码(含工具静态分析)

  • 设计了多少测试(用例)

  • 开发了多少自动化测试脚本

  • 执行了多少测试(用例)

  • 报告了多少缺陷

  • 每天在测试上花了多少时间

  • 数量增长率


3. 测试的有效性和效率

  • 缺陷数/百个测试用例数

  • 缺陷数/脚本KLOC

  • man-hour/功能点(或用户故事)

  • 自动化测试百分比

  • 缺陷存活时间

  • 测试预算或投入占整个研发比重(适合团队)

  • 回归测试所占比重

  • 每天发现的缺陷数

  • 每天设计的测试用例

  • 每天开发的脚本行数

  • 有效性提高速度

  • 效率提高速度


4. 有哪些突出的成绩或事件

  • 测试专利申请或被批准数

  • 产品特性较大改进的建议被采纳

  • 测试过程较大改进的建议被采纳

  • 克服了某个测试难题

  • 克服了某个测试瓶颈

  • 一种新的且有效的测试策略

  • 一种新的且有效的测试方法

  • 发现新的缺陷模式(故障模式)

  • 提出并设计了一款测试工具

  • 开发实现了一款测试工具

  • 解决了某种测试过程或结果的度量

  • ......

(看完这些KPI,测试开发在里面只是其中几项,并不是很突出)


如果你还觉得没破这个梗,需要付费,

邀请作者专门去实地调查研究

制定方案,彻底破这个梗

文章已于修改

    发送中

    本站仅按申请收录文章,版权归原作者所有
    如若侵权,请联系本站删除
    觉得不错,分享给更多人看到