怎样合理的对测试人员提交的有效缺陷数进行考核

zwaxjl

公司测试部最近要重新整理测试工程师绩效考核管理办法，根据公司实际情况制定了相应的考核策略。但是，在对于如果合理的评价测试工程师提交的有效缺陷数和缺陷等级这里，感觉比较矛盾。
1.根据分配任务大小的不同的测试工作
2.对于系统升级、补丁或是维护的测试工作和新开发系统的测试工作
3.负责开发的人员技能水平不同，体现出模块质量的不同
等等，还有一些原因，导致测试人员提交有效缺陷的数量肯定不同，那么问题是：在这种情况下怎么合理的对测试人员提交的有效缺陷数进行打分呢。
对于测试人员的考核，对于提交有效缺陷数和质量基本在所有的能搜索到资料里面都体现了作为一个基本考核指标出现的，我本人也认为这也应该作为考核指标的一个点，那么问题是：这种情况下怎么合理的对测试人员提交的有效缺陷数进行打分呢？它能够或者适合做具体的量化标准吗？
欢迎大家给出不同的意见，或是一个合理的关于bug有效缺陷的合理考评方法，谢谢？

lampson_82

楼主所提问题的确是需要正视的情况，以下仅说明个人想法
1.按缺陷数
  优点：考核方便         
  缺点：对于测试人员极不公平
2.按缺陷严重等级，比方说3个严重=1个致命，3个一般=1个严重，3个提示=1个一般
  优点：考核也比较方便
  缺点：测试人员可能把重点关注于级别高的缺陷
3.按市场反馈情况
  优点：对测试人员而言比较公平
  缺点：测试完项目后不可能很快投入市场，需要等待很长时间

楼主如果觉得以上都不合理，可以改变下分配方法，可以细分需求，让每个测试员都测到同样的需求，只是测试子项不同而已。

zwaxjl

大家多多说说自己的看法啊

momang

你好
从你们两人所说的 可以看出
你们给 测试人员的绩效考核片面的理解成了对他们所提bug的数量 质量等的考核

其实 要对一个测试人员进行考核，有很多可考核点
发现的bug 只是其中的一个因素而已

例如，可以通过用例的完成数量 和完成质量来考核
可以通过脚本的完成数量及完成质量来考核
还有每个测试人员的工作态度、是否积极主动 是否善于沟通等等
都可以做为考核点点
还可以在月初 季度初 年初 leader与员工根据任务 共同商议一个考核指标
若到了考核的期限，看达成指标的程度 也可以做为一个考核因素

还有让测试人员 自己写总结，总结自己这个考核期里 自己觉得自己做的怎么样
什么地方做的好的 什么地方需要加强的 什么地方需要完善的 等等
让他们自己给自己打分   

还可以让 测试人员间 互相评分，大家每人都写出 这个考核期  哪位测试人员做的好
该怎么排名， 他们在一起工作的  对彼此应该了解  从他们自己的互相评比中 是最客观的

当然 还可以 让开发人员来对测试人员来评分
当大部分开发都夸某个测试人员工作干得不错的时候，我相信 他一定不会差到哪里去的
当几个开发都在说某某测试 干得很不好的时候，那这个测试一定有问题，或是工作能力不行
或是工作方式不好，或是工作态度不积极 甚至是沟通方式不合适

等等等等

可以根据自己公司的实际情况
来适当增加 或减少一些考核的点和因素

测试人员考核 不能只针对bug来考核


另外  统计bug 的各种数据

可以作为研发部门的里各个分部门的考核点

下一楼再详细说明

momang

统计bug 的各种数据

可以作为研发部门的里各个分部门的考核点

下一楼再详细说明


首先 大家想到的  就是bug 的数量了， 数量是最能直接反应一个测试人员的工作情况的
其次是bug质量，bug严重等级等等

另外 bug 数还可作为开发人员的考核指标之一，如某个开发人员 平均每天5个bug 而其他人员 平均每周5个bug   那么 时间久了  这个开发人员的开发质量问题
还有 bug的修复时间很长  若某个开发人员修复一个bug需要一周左右甚至更久，而其他开发人员 基本是当天就能解决的，那么时间久了，大家久会发现这个人的解决问题的能力不行
再者，开发人员修复bug的通过率，也可以作为开发人员考评的一个指标
  如某个开发修复了一个bug ，但是测试人员测试下来，发现问题没解决，或是这个问题解决了，但是引出了另一个新问题， 其他开发人员修复bug的一次通过率比较高，那么长期下来，这个人的工作能力也会得到大家的质疑的
还有等等等等

除此之外，bug还可以作为需求人员、设计人员、配置管理人员等等的考核指标之一

如 100个bug中  有10个因为是需求不明确导致的 那么需求文档质量不高，不够详细
  再如   100个bug中 其中10个严重的bug 是由于设计的时候没考虑周全，在设计的时候就有问题， 那么 这个设计人员的工作可能做的不够好
再如 100个bug 其中20个 并不是程序本身的原因，而是配置管理人员在这个版本中打了上个版本的文件等情况造成的  拿这个事实说明 配置管理人员的工作很混乱
还有 100个bug中 还有5个是由于测试环境的问题导致的，换了一个环境OK的  那么环境管理人员 是否该为此负责呢？？


人员考核  关系到 员工晋升 加薪 转正 福利  职称等 等 各个方面
是件很严肃的事情， 需要慎重对待  为了更加合理的进行考核
应该从多角度，多维度 去考核，而不能只靠单一指标来进行
那是一种不负责任的做法    需要极力避免之

米兰卡卡

就像楼主所说的，根据bug数目去考核，这当然不公平了，程序员的好坏等等都有影响啊！我们既然对客户负责，那么客户的反馈信息可以作为一种考核的办法，当然了还有你工作的态度，沟通能力等等！我想慢慢的会形成一种良性的公平的考核制度