Day5-8测试积点任务
问题：对于将测出的 bug 数作为对测试人员绩效的评价标准大家怎么看？对于将测出的bug数作为对测试人员绩效的评价标准大家怎么看？是这样，最近公司突然提出要以提的bug数作为绩效的考量标准。大致的考量规则如下：1、对于在测试过程中发现bug的数量&质量排名前5%的同学，春季薪酬调整时不论是否晋升，调整幅度确保在前20%；——适用于所有人
2、对于反馈产品线上有效问题数量&质量方面排名前5%的同学，春季薪酬调整时不论是否晋升，调整幅度确保在前20%；——适用于所有人
3、对于在产品问题的分析、跟进、解决方面表现突出的同学，我会在技术职称评定中以尽我所能，以最强烈的方式建议晋升；——适用于技术类工程师
4、对于在第1、2、3条上表现突出的外包同学（前20%），优先于社招&校招，转为正式员工；——适用于所有外包工程师
5、对于反馈产品线上有效问题的数量&质量方面排名后10%的同学，不建议参加技术或管理晋升；——适用于所有人
6、被反馈有效漏测问题数量最多的前60%的线上产品，其主管绩效不能是1和2；——适用于所有管理类和实习项目经理大家对这种评价标准有什么想法？先说一下我的吧，我个人觉得，首先以bug数做为评价标准是一种很不公平的做法，对于不同的产品线、产品类型，客观上会影响产生的bug数，老的成熟的产品线bug肯定相对少一些，新的产品bug必然会多一些，有些走敏捷开发的产品线可能rd和qa很紧密的沟通，有问题直接解决了，也不会提bug。所以这个评判标准我觉得首先是不公平的。
抛开公不公平，这种以提bug的方式来考量绩效我也觉得并不合理。第一，大家可能工作本身已经相当饱和，而提bug肯定需要有个流程。我觉得一些重大的，值得后续注意的的确很需要记录下来，但是一些简单的代码错误，或者完整性判断，或是上线步骤的一个错误路径等等，可能本来和rd提一句就能搞定，但是一这样鼓励提bug，可能所有的测试人员天天就提bug了，不利于工作进展。第二，我觉得开发人员和测试人员应该是很协调的两种角色，事实上目前我们的团队中也就是这样的，但是这样把bug引入绩效，很容易造成测试人员与开发人员的对立。到时候本来商量一下改改的问题变成了这是不是bug的互相扯皮，很不利于团队的关系。第三，对于线上bug的发现，我觉得的确很重要，可以让大家更关自己的产品，提高产品质量。但是如果把这个当成如此大的一个考评指标，我觉得会让测试人员天天就盯着线上了，一天到晚就去搜线上问题呗，反而无心去关注实际项目的进展。我觉得这种方式对于一个正在发展的团队是很不利的。回顾线上问题是一方面，另一方面我们还是要多关注于那些新项目，新的测试方法，开发新的测试工具或者研究新的测试流程，这样才能推动发展。
当然以上只是我个人的一点不成熟的想法，希望大家可以讨论下哈~~~ 这也是公司激励的一种方式，只是仅仅已bug数量为标准，不是很赞同 我也不赞同用BUG数量来衡量，但是一般对于新员工来说，公司还是倾向于用BUG量来衡量。个人感觉对于用BUG量来衡量，不如用遗漏的BUG量来衡量更好些。 这种方式容易导致测试与开发的矛盾，逼迫测试将某些问题计算成bug，增加扯皮和修改时间 要关注上线后问题，而不是关注发现的问题多少 不是很赞同，虽然有提到bug质量。但是这种方式很容易激化开发与测试之间的矛盾，而测试也可能存在为了找bug而找bug 仅仅bug数做绩效考评确实不合适，建议可以使用bug率、bug的严重程度等多个标准作为考评； 不赞同BUG数量，建议BUG质量和深度
页:
[1]
