微信号:grzlwx

介绍:光荣之路官方资讯

怎样把测试结果与开发人员的绩效考核联系起来

2016-01-17 22:47 光荣之路

吴老的《selenium webdriver 实战宝典》出版了!

楼主:有没有什么好办法把测试的结果,和开发人员的绩效考核联系起来? 现实情况是:一个开发小组里的开发人员,他们各自完成的任务数量不相同。怎样将bug数量和严重程度,定位到个人?

==============================

考核绩效也是容易的。重点的是如何量化,量化的不好,下面被考核的肯定不满,量化的太简单,下面的都是搞软件的,他们能倒推不出来你的算法?从而商量好大家一起拿高考核?

考核第一个是量化工作量。
如何量化?
这个是有前提的。你们的需求搞的很细。开发流程测试流程非常清晰并且能执行下去。
为什么需求要搞细,细了就能靠WBS颗粒化。一旦颗粒化就能给开发人员分配颗粒工作,颗粒是可以数的,所以开发人员一定时间内的开发工作量就能量化。

开发完了,不是说他的事情就完了。开发完后得给测试人员进行测试(一般公司都这流程,如果是测试提前的那类流程,请参考这个思路),开发完的颗粒给予测试人员,每个颗粒化后的开发完成品,发现的BUG数,就可以量化,此处开发人员的每个颗粒化后的完成品缺陷率就能统计,测试人员发现缺陷数、每个颗粒化后开发完成品的发现缺陷率也能统计。

缺陷找完,给予开发人员修改,修改就会有开发人员一定时间内的修改效率。
修改完毕,给予测试人员回归测试,就有测试人员的回归测试缺陷数、每个颗粒化后开发完成品的回归测试发现缺陷率。

统计出以上几个数字,然后按照一定你们公司的公式就能把奖金和考核挂钩,而下面的人员没有意见。也减少了测试和开发的对立性。
===========================

聊天记录

学习测试
本来用BUG数量来对开发和测试进行考核就不是明智之举
学习测试
开发的Bug多就代表他不努力,水平差?也要看别人模块的难度以及别人的代码量
破海葬天灭地
- -群主看了一半
破海葬天灭地
WBS是王道
学习测试
测试员测出来的BUG少就代表他们不努力,水平差? 那万一别人软件质量就是高,或者测试用例写的不好呢
破海葬天灭地
颗粒到类到方法的程度,分到人头上,工作量就可以度量了
破海葬天灭地
不仅仅看BUG数量哦。。综合起来看的。
学习测试
这个问题一直感觉是个难点
学习测试
很多manager都是通过感性来考评的
破海葬天灭地
肯定- -那个方案只是理论,执行下去的难度不是说说那么简单那
学习测试
量化的数据少
学习测试
量化的数据一旦取的不合理或者片面了,很容易造成下面的人不满
学习测试
这个问题需要深层次的讨论了
学习测试
给那个楼主最好的意见就是引导他的领导尽量不要只用BUG数量来进行考核
ゞ珍惜27
计算方法:严重*bug数*0.5+中级*bug数*0.3+低级*bug数*0.2,
补充:谁的数量大,那么,绩效的该项就对应低。
学习测试
灭地的回复容易让楼主感到似懂非懂的感觉
破海葬天灭地
工资+项目质量评定考核比例X奖金+个人工作量奖金(这个是娱乐用)
破海葬天灭地
宏观点,就简单了
青苹果
上面的讨论很有意思,学习啦
破海葬天灭地
不管测试组程序组做啥事,目的是提高质量。
破海葬天灭地
那么只需要评定项目质量
破海葬天灭地
就全部人员考核完成
学习测试
我们公司也都正在尝试新的考评方案
学习测试
以规避以往方式的不合理性
破海葬天灭地
这个是我给我们公司的简单方案
破海葬天灭地
刚开始的那个,大家都赞同,都说好,执行起来不到3天,所有的地方亮红灯
学习测试
不管怎么样,考评方式就要尽可能的体现开发效率和测试效率的重要性
学习测试
所谓效率就不单单是量的问题了
破海葬天灭地
我当时还自己做了个考核系统- -结果也被搁置了
破海葬天灭地
光WBS。。颗粒到类到方法,就没人敢接招
学习测试
走管理路线也不是非常容易的

===============================

直接衡量肯定是不对的。
第一 需要有历史数据的支撑
第二 每种软件的难易度不同 前台UI 后台业务模型 导致的Bug数都会有区别
现在我见的比较多的是 每千行代码Bug数的统计
==============================

如果项目经理给开发人员分配模块的时候,可以随机的或者有意识的把模块平均分给各个开发人员,并且每次分配的时候根据模块难度要在开发人员中轮转。比如这样第一次A君得到一个比较容易的模块,下一次就应该获得分配一个更难点的模块。在一定时间后,每个开发人员开发模块所关联的bug数量和bug的分类(严重性和优先级)所占的比例就大概可以反应出这个开发人员的水平。

但是这样做仍然不能做到量化,也不能做到很准确。

如果开发人员技术不在一个水平上,这样的办法就行不通。一般情况下,10年工作经验的开发人员比新手获得的任务模块都要难一些,有些活是新手干不了的,如果让新手去干干不了的活,必将造成这个模块的开发失败或者加大这个项目的风险。

应该把整个团队当做一个总体来看,只要项目成功,团队就成功了,只要不是个别开发人员和测试人员表现太差,就是人人的成功。

当软件版本被放出去后,如果软件达到了软件需求也没出现Bug,则应该认为是开发人员和测试人员都表现好。

如果出现了bug,迅速修复的同时应该清查造成bug的原因,是需求分析的原因,设计的原因,开发的原因还是测试的原因,这些bug的出现都应该对应该承担相应责任的员工的考核起到减分的作用。

出现bug一定会牵扯到测试人员,是测试人员的测试用例中涉及到这一项还是遗漏了这一项,测试用例中存在这一项的话是否是测试人员未执行或者遗漏了这一测试,是否超出了测试人员的能力范围或则工作范围,测试人员对于一些情况是不用承担任何责任的。

(作者:赖因斯坦 来源:http://blog.sina.com.cn/s/blog_51dc0fba0100nq0x.html)

为了保证产品质量,你认为要如何考核开发人员(和测试人员)呢?😊

公益传播测试知识、技能与正能量!感谢作者!
分享测试生活,思考测试人生!欢迎投稿!
文章图片来自网络,如有侵权请见谅,请联系我们妥善处理。
735821166@qq.com

光荣之路
软件测试培训


官网:www.gloryroad.cn

微信公众号:gloryroadtrain

性能测试QQ群:415987441
测试招聘QQ群: 203715128
自动化3群QQ: 371211499

Python群:457561756


 
光荣之路 更多文章 今天晚上的 linux 公开课- Awk 编程 7月28日(今天)晚上的 linux 公开课- shell编程 8月4日(今天)晚上的 linux 公开课- shell编程 9月1日(本周一)晚8点半,光荣之路Web自动化系列基础课—javascript第二讲 推荐本好书《与机器赛跑》
猜您喜欢 PEP 0257 -- Docstring 约定 6月25日CocoaChina(广州)线下聚会诚邀您的光临 内存泄露从入门到精通三部曲之基础知识篇 Kubernetes In Rancher 收藏!斯坦福Andrew Ng教授“机器学习”26篇教程全译