问答 公司准备实行绩效制度,想问问各位大佬有没有好的建议~如何评估测试部门的绩效

Kori · July 09, 2019 · Last by 无名 replied at October 08, 2019 · 2802 hits

如题~

共收到 14 条回复 时间 点赞

最简单直接暴力——发现缺陷数

测试覆盖度,个人贡献度来作为绩效更好吧。之前看过一篇文章。
等我翻翻找到了再给你回复。

applepen 回复

哈哈,好有耐心,好同志

是要评估整个测试部门的绩效,还是想了解测试团队每个人的绩效应该如何考量?
如果是团队的话,建议看看这个帖子:
https://testerhome.com/articles/17888

个人经验:做绩效考评首先第一点是明确目标、第二个是找到数据的量化点,尽量把目标能通过数据量化出来;比如目标可以是某某需求达到完美上线标准、完美上线标准要尽量量化出来:比如上线后 3级BUG反馈少于 5个;无 1、2 级BUG

仅凭bug数肯定是不行的,怕是会为报bug而报bug。测试文档输出、上线后反馈、bug数、产品建议这些都得综合起来看吧

simple 回复

感谢分享,很有用,不知道我的理解对不对,我举一个脑补的测试部门的OKR实例大家帮忙看看:

本周关注的任务:
P1: 上月所有版本问题回溯分析
P1: 本周版本回归
P1: xx工具分享

OKR当前状态:
目标:提高发版质量
关键结果:线上资损率25%(2500/10000)
关键结果:月均缺陷率
关键结果:持续改进措施覆盖率(版本覆盖率:37/50,资损覆盖率:1900/2500)
关键结果:人员技能提升(新工具推广3/12团队)

未来四周计划:
推动所有团队的版本回溯
工具推广应用
检查预防措施执行情况

状态指标:
缺陷率持续下降
人员单位产出增加

看了你们半天了 没说到点子上,绩效考评, 一句话 “会哭的孩子有奶吃” ;

年初时候公司也要求出类似的文档,经过搜集百度上的文档加上结合公司实际情况思考出以下维度:

可以量化的有以下:
考勤情况,简单的来说就是禅道或考勤系统的活跃天数
测试用例的个数与规范,即总共编写的用例个数以及规范情况,通过百分比方式进行加减分,如前20%加一分,后20%减一分
测试用例的有效率,即通过评审的用例个数与总个数的比例,这样可以控制不去为了写用例而写用例,通过百分比方式进行加减分,如前20%加一分,后20%减一分
BUG的个数与规范,即总共提交的用例个数以及规范情况,通过百分比方式进行加减分,如前20%加一分,后20%减一分
BUG的有效率,同理用例有效率,通过百分比方式进行加减分,如前20%加一分,后20%减一分
历史BUG的个数,即超过多长时间未处理的BUG数,可检查人员对BUG的跟踪情况,一个减多少分,多少个是上限
因为公司测试还需对产品进行维护,所以特地加了一个对于维护方面工作的加分

主观的就和网上差不多了,如:行为规范,工作规范,文档规范,执行力,责任心,沟通,工作的完成情况,工作的质量

绩效需要有主观和客观指标

一个版本分成N个小需求,然后分配到个人,最后统计个人的总需求量,以及其中发现bug的需求量。

这个要根据你们公司的情况来定吧,不同公司情况不一样,关键是测试部门目前的主要职责是什么、你通过绩效评价做到什么。

如果主要的工作是发现缺陷,那可以从需求和缺陷的发现比率来评估,做到大家多发现缺陷。
如果主要的工作是预防缺陷,那可以从平均需求发现缺陷数量降低的速率来评估,做到缺陷少出现。

我觉得测试最重要的还是对你要测的产品有所提升,无论是产品的质量,还是开发组的效率,其实都可以靠测试的

  1. 产品release周期多少,能不能继续缩短?自动化release吗?
  2. 测试对feature的覆盖度?或者测试对生产环境的覆盖度?
  3. 测试要跑多久?能不能再提高?

不清楚你们产品和测试的规模,所以也很难继续想更多的细节

拍马屁的绩效为S,非常听话的绩效为A,一般听话但产出还可以的为B+,一般听话但产出不好的为B,不听话但产出还可以的为B,不听话且产出不好的为C。

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