51Testing软件测试论坛

标题: 如何进行BUG的绩效考核？ [打印本页]

作者: 森林一木 时间: 2007-4-4 14:42
标题: 如何进行BUG的绩效考核？
大家好，小弟碰到难题，老大要求对各个研发组进行排名，其中有种排名方法是用BUG进行考核，大概意思是通过BUG的趋势，反映出个研发组在项目实施过程中的工作质量。他仅给出了方向，但没有给出具体办法，需要我写出具体的考核方法。

目前我们是用TestDirector进行bug的管理，当中也有一些字段可以利用，但我现在没有一个比较好的思路。望大家踊跃发言，帮忙考虑一下，谢谢大家。

作者: luming 时间: 2007-4-4 15:01
这个东西不好弄。很容易出问题。
大概想到的一些思路。

必须规定好缺陷的严重性，最好有一个专人对严重性进行设定。
每个缺陷都需要确认是否是真正的缺陷。
不同的严重性进行一定的加权，还有对项目最后剩余的不修改的缺陷，引入加权。
最后把这些加权数和总缺陷数进行比较，得出质量系数。
可以通过不同的加权在各个项目组平衡一下。
引入缺陷处理时间的曲线，可以督促开发尽快处理缺陷。

呵呵，实行后，恐怕提出很多缺陷的人会被开发bs了，开发也会尽可能的开脱自己的责任。

作者: tongke 时间: 2007-4-4 17:52
楼上提出的思路不错,只怕搞得测试和开发的关系越来越紧张...呵呵

作者: 森林一木 时间: 2007-4-5 14:24
领导要做这样的工作，也没办法。只好把相关的刑事权限给相关的项目经理了。测试人员不能直接与研发人员打交道。

作者: nsforever 时间: 2007-6-7 10:59
我也有同样的问题,不知LZ是如何做的,可否提供一点方法,思路.

作者: zdrqq 时间: 2007-6-14 09:08
　其实这样做对测试人员也有一点点好处就是，研发人员人提交测试之前，会加强自测．呵呵

作者: jmy_1981 时间: 2007-6-14 17:34
标题: 反对！错误的多少不能直接反映一个开发或测试的好坏的。
试想一个初级开发，工作仅仅是为代码写注释，那他千行代码出错率为零。这和一个写底层或者写接口技术的高级程序员千行代码出错率为30或40相比，有可比性吗？

作者: andrewchou 时间: 2007-7-30 16:00
自己测试可以测试逻辑错误。不过自己测试花的时间和得到的效果不能成比例的

作者: guanyijing 时间: 2007-7-31 19:59
其实软件缺陷评估的方法相对比较多，从简单的缺陷计数到严格的统计建模，基于缺陷分析的产品质量评估方法主要有以下几种：
缺陷密度——软件缺陷在规模上的分布
缺陷率——缺陷在时间上的分布
整体缺陷清除率
阶段性缺陷清除率
缺陷趋势、预期缺陷发现率

作者: guanyijing 时间: 2007-7-31 20:10
标题: 回复 #1 森林一木的帖子
其实软件缺陷评估的方法相对比较多，从简单的缺陷计数到严格的统计建模，基于缺陷分析的产品质量评估方法主要有以下几种：
缺陷密度——软件缺陷在规模上的分布
缺陷率——缺陷在时间上的分布
整体缺陷清除率
阶段性缺陷清除率
缺陷趋势、预期缺陷发现率

作者: yzbin097 时间: 2007-8-1 21:52
这样的考核不完整啊sdlkfj3

作者: 菲儿2007 时间: 2007-9-19 10:12
标题: 测试人员如何进行绩效考核
发表一下我的看法：我们公司使用辅助测试系统mantis进行BUG的记录（指派、新增、已回归等），所以我们的考核表是：
1、质量考核部分我们设定的是：新增bug数和已回归bug数，以此计算分值，凡高于既定值加分，凡低于既定值减分；
2、工作态度（考勤、纪律）
3、计划管理（有无制订计划、计划是否执行，执行结果如何）
4、附加部分（在计划之外所做出的贡献）

附加部分是在总分值之外的分数

以上只是我的一点小经验，供参考

作者: cjh0901 时间: 2007-9-20 09:28
测试人员与开放人员的关系，很难和谐

作者: 闻欣 时间: 2007-9-30 21:27
必须规定好缺陷的严重性，最好有一个专人对严重性进行设定。
每个缺陷都需要确认是否是真正的缺陷。
不同的严重性进行一定的加权，还有对项目最后剩余的不修改的缺陷，引入加权。
最后把这些加权数和总缺陷数进行比较，得出质量系数。
可以通过不同的加权在各个项目组平衡一下。
引入缺陷处理时间的曲线，可以督促开发尽快处理缺陷。
一定要是对事不对人的做法，否则很容易出问题

作者: sunlaomi 时间: 2007-10-5 04:17
看成果吗～

作者: mistletoe82 时间: 2007-10-8 23:28

原帖由闻欣于 2007-9-30 21:27 发表
必须规定好缺陷的严重性，最好有一个专人对严重性进行设定。
每个缺陷都需要确认是否是真正的缺陷。
不同的严重性进行一定的加权，还有对项目最后剩余的不修改的缺陷，引入加权。
最后把这些加权数和总缺陷数进行 ...

想法很好，但是过于复杂，甚至偏学术。有很多地方都会不好操作。
1.确认每个缺陷真的是缺陷-这里就不好做，有的时候defect和enhancement是很难区分的
2.严重性加权-加权系数如何划分？如果一个大型产品的不同开发组，就很难办。假设某一个开发组A都是开发核心业务逻辑，另一个开发组B都是界面，那A组的系数永远比B高，相应出了问题受“鞭挞”的概率也一定高，这对A组是不公平的
3.缺陷处理时间曲线也受很多客观因素干扰，不是developer接到一个defect马上就会处理的，因为他也有开发任务，而且不同priority的缺陷是不一样的，这里也得计算进去。
总之，这是一个很复杂的问题。我觉得它可以作为一个工程硕士的论文题目，比如《利用加权法进行bug绩效考评》什么的哈哈
这是个好题目

作者: njalic 时间: 2007-10-9 13:51
根据BUG数据来统计工作质量，最终的结果就是大家都流于形式，应付而已。
所以在制定绩效考核的时候除了需要将BUG当做一个指标来实施以外，还需要考虑如：工作质量，工作效率，工作态度等问题。
将这些指标进行一个合理的加权值，这样看起来就公平很多了。
看你们公司项目的规模了，都是些大项目而且时间跨度都很长的话还是别这么做了，小项目用BUG统计比较合适。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)