看啥推荐读物
专栏名称: jb
Tester
目录
相关文章推荐
今天看啥  ›  专栏  ›  jb

JB的测试之旅-测试岗如何进行业绩考核?

jb  · 掘金  · 测试  · 2019-02-15 09:27
阅读 13

JB的测试之旅-测试岗如何进行业绩考核?

前言

写本篇的原因很简单,18年结束了,要给自己及其他小伙伴做下总结

以前呢,都是自己做总结,围绕的无非就是对团队的贡献个人成长

但是现在不一样,需要帮小伙伴做总结,也需要为测试团队做总结,突然觉得压力山大,而且也要给优秀同学提名奖项;

因此,就有了本篇的内容,目的很简单,测试岗在评绩效时,到底有哪些维度

image.png-58.4kB

业务测试

测试岗位的分工,粗略分为业务测试测试开发,两者因岗位的不同,而要求自然也会有区别,这里就先聊聊业务测试;

从结论而言,业务测试肯定是第一位的,是产品的基础,因此围绕业务会有很多衍生品,比如性能、兼容性、稳定性、安全等等,尽管如此,业务测试还是最重要的;

而在业务测试过程,考查的是什么?

  • 思考问题的角度,如用户角度、测试角度、运营角度;
  • 测试基础知识,比如目的、原则、模型、项目流程、用例设计方法、测试方法和类型;

上面提交到的测试基础知识,这里补一下:

知识点 说明
目的 发现程序中存在的错误、为反馈信息做准备;
原则 尽早进行软件测试、所有的测试都要追溯到用户需求、需要在有限的时间跟资源进行完全测试、测试是证明软件存在问题、关注测试中集群现象、避免测试的随意性;
模型 V模型、W模型;
流程 需求评审、测试计划、用例设计、执行测试
用例设计方法 黑盒(等价类划分、边界值)、白盒(语句、判定、条件、路径覆盖);
测试方法和类型 按代码可见程序划分(黑盒、白盒、灰盒)、项目流程阶段划分(单元、集成、系统、验收测试)、按执行过程上花覅需要人工干预(手工、自动化)、其他维度(冒烟、回归、随机、压力、负载、性能)

传统的业务测试,从用户角度和测试角度思考问题,价值体现在扎实的测试基础知识、发现问题的敏感性、业务知识的专业性、业务提议的建设性。

随着敏捷、快速迭代的兴起,对业务测试的要求越来越高**,缩小问题范围、精准定位原因,节约开发耗时**成为业务测试的另一种价值体现。

考核点

如果非要说考核,个人觉得有几点:

  • 工作质量;
  • 工作效能;
  • 工作积极性;

工作质量

这里面包括用例质量、系统质量等方面进行考核;

用例质量,可以用总有效缺陷除以用例总数,得出单位用例的缺陷检测率,用以考核用例的质量;

系统质量,主要考察有效缺陷质量、缺陷漏测率、有效缺陷比、各级别缺陷比重等指标;
复制代码

工作效能

主要考核测试人员整体工作效率;

主要指标包括:

  • 设计效率;
  • 设计覆盖率;
  • 执行效率;
  • 执行覆盖率;
  • 是否在指定时间内完成工作任务(主要考察实际和计划的偏离度)

积极性

主要考核测试人员沟通、学习等方面的能力。

  • 测试过程中问题的反馈;
  • 解决测试过程中出现问题的能力;
  • 在项目阶段测试完成后的真空期进行测试学习的能力;
  • 查看研发设计文档, 进一步了解需求,再进行需求分析和用例设计;
  • 各种提高效率的产出,比如流程优化、过程改进、自动化、脚本、工具等;
  • 主动学习测试理论或相关技术;

特别注意

这里特别说明,不能用bug数量来做kpi,因为不同同学分工不同,产品功能都不一样,什么bug数量,bug严重度,设计,执行,维护用例的数目都不是合适的考核指标。

另外,如果遇到一个能力差的研发,那kpi绝对是第一的,变相的,测试就希望研发的能力越差越好,同时,乱报Bug的情况会增加,最后可能会影响项目进度;

最终产物

整理下,如下图,bug数个人不赞成,但实际有不少公司都是有这个指标的,因此还是列出来的,建议不要使用

image.png-98.5kB

站在更高点的角度,就变成这样:

image.png-67.4kB

测试开发

业务测试因为有明确的业务方需求,因为工作成果度量是很明确的,那测试开发岗呢?

首先要明确一个概念,测试开发岗核心是提高内部效率,如开发各种平台,让数据更清晰、能让项目各角色更顺畅的交付;

测试开发的客户是内部团队,因此必须懂/熟悉业务,知道团队痛点,具备测试跟开发的思维,不然,不为业务服务的工具都是虚的;

节省时间

某同学A每天要花2小时做一件事,如果把这件事工具化,那就能节省该同学2小时,如果有10个同学也需要做这事,那么这工具就节省了20个小时了;

这个时间怎么算?常规的做法就是次数 * 耗时

眼看这个维度是很合理的,jb也尝试过一段时间,但是最后会发现一个问题,就是这个指标不好度量,还是上面的例子,同学A的2个小时空闲出来了,还是就需要做其他事情了,其他事情可能会导致他更加忙了,那从项目的角度,比原来更忙了,哪里算效率提升了,久而久之,大家都觉得这个指标不靠谱了;

另外,工具的推动,也是极其困难的,做工具跟做产品是一样的,都是一边迭代一边优化,如果没有用户,这个工具就成了一句空话了;

如何吸引更多的用户?就需要去推动,花更多的时间在写文档上、培训,试点等一系列操作;

次数

一个好的工具,只要能真的解决问题,肯定会有用户,而且会经常使用,站在这个角度,用次数来做指标,是一个方向;

各种成本

如果这个工具能带来收益,或者减少支持,比如原来用的是收费第三方应用,现在是用内部的,这部分费用就节省下来了,也是一个指标;

其他

除了次数,还有很多指标:

  • 问题发现数,如自动化;
  • 工具\平台稳定性;
  • 口碑;
  • 需求数;
  • 使用情况;

小结

好了,说到这里,也差不多了,简单总结下指标吧;

对于业务测试:

  • 工作质量;
  • 工作效能;
  • 工作积极性;

对于测试开发:

  • 节省时间;
  • 使用次数;
  • 问题发现数,如自动化;
  • 工具\平台稳定性;
  • 口碑;
  • 需求数;
  • 使用情况;

就这样吧,谢谢大家~

1-140R3154U8.jpg-9kB




原文地址:访问原文地址
快照地址: 访问文章快照