51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 15751|回复: 43
打印 上一主题 下一主题

[讨论] 测试人员绩效考核

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2012-3-1 17:08:04 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
公司要求我编写测试人员绩效考核,内空可查看附件希望各给点意见

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2012-3-2 11:18:54 | 只看该作者
个人不太喜欢把加班作为考核内容
有可能出现加班完成本该工作时间内就该做的事
一般把加班算到工作态度项里进行考核
全部客观不现实,而且也需要掌握一定的主观评价权力
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    3#
    发表于 2012-3-2 16:35:17 | 只看该作者
    我更建议以一段时间之后的用户反馈bug数量作为测试有效性的依据和考核依据。这个比较真实一些。

    另外,个人觉得若计划充分,加班应该扣分。

    加班期间测试出的Bug是平常的Bug分值的2倍,员工加班可按小时个数加分(1分/小时)
    这个规则有点坑,感情这里1分大概能等于多少RMB来着的。如果不能,那这个还是算了。

    举例来讲,一个项目的测试出来各阶段的bug数量是可以估算的。粗略的说,一个N万行的系统,所能接受的bug数量应该是多少是可以定义的。所以,觉得以bug数量作为考核依据实在有点不妥。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    4#
    发表于 2012-3-2 16:36:05 | 只看该作者
    1.若是代码错误方面的Bug分值相应的要增高
    2.若是界面优化、标准规范方面的Bug则分值要相应减低
    3.若是需求变动、新增需求这个要跟项目经理确定后若修改后对系统使用和界面更符合客户则分值可相应的再增高些


    这些个觉得是没啥用?增高怎么计算,减低如何计算?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    5#
    发表于 2012-3-2 16:38:59 | 只看该作者
    若是在测试前用来写测试用例则分值正常打分,若是边写边测则用例分值要扣除一半(因主要分值都体现在Bug上),若是测试完成再写用例则用例分值就是正常的4分之一

    这种情况要建立在良好的开发过程上,如果本来开发过程中决定了测试必须在编码结束后介入,又因为上线要求的关系,必须在特定时间内上线,对测试人员而言,起点就是不同的。

    在大量的实践中,边写用例边测试的情况很常见。但是用例内容应该是和测试内容错开的。已经编写用例的部分才能进行测试。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    6#
    发表于 2012-3-2 16:40:37 | 只看该作者
    整个文档中,对于加分和减分的部分规则是很不明确的,也没有上下限的说明。

    比如这种情况:
    了解客户的需求                 以小时来打分,1小时1分。
    晕,整个测试过程中,假设:我花了10天解读需求,那么岂不是一下子就80分了??
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2012-3-6 14:44:49 | 只看该作者
    说实话用bug数量来量化不行的,测试人员发现多少bug和开发质量有关。个人觉得bug的数量和严重程度可以用来考核开发
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2012-3-6 17:02:42 | 只看该作者
    持续学习中哟,最近部门也是喊我出一份测试组的考核办法,有点头疼
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2012-3-8 20:44:34 | 只看该作者
    顶!顶
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2012-3-12 20:17:23 | 只看该作者
    回复 3# archonwang


        我比较反感用BUG数衡量一切,但是没有BUG又不能说明一切。所以bug只做辅助考核
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2012-3-12 20:17:36 | 只看该作者
    回复 3# archonwang


        我比较反感用BUG数衡量一切,但是没有BUG又不能说明一切。所以bug只做辅助考核
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2012-3-13 14:05:36 | 只看该作者
    我觉得用测试后发布上线之后,用户发现BUG的问题数作为考核测试人员的指标会更有参考意义。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2012-3-13 15:50:52 | 只看该作者
    我是新来的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2012-3-14 09:43:55 | 只看该作者
    个人认为这份考核没有人会同意的,太含糊了而且不符合实际
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2012-3-14 11:02:38 | 只看该作者
    新来的啊 不知所云
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2012-3-14 11:28:57 | 只看该作者
    其实大概差不多就可以了,不过这个绩效还是让所有员工进行查看通过并同意,就可以执行了,执行一段时间后可以再次召唤员工来多一次会议讨论嘛。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2012-3-14 16:38:10 | 只看该作者
    这个业绩考核一般。
    个人观点:
    1. 上级安排的任务,是否有效时间完成
    2. 加班是因为上班的时候不给力造成的,还是的确一直在忙,工作量大造成?这个玩意儿很监控,最好的方法就是参见第一条
    3. bug的数量与测试、开发都有关系,所以不要考核数量,更多的关注流出去的bug,当然也要看项目的大小,大项目应该流出的比较多,可以算流出率
    4.用例的质量,不能看个数,要看有无遗漏的用例。一条用例可以拆成两条写,也可以并成一条写,这就是漏洞

    ..........
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2012-3-14 23:29:52 | 只看该作者
    说实在的,这份考评太复杂,可执行(可量化)性不高。
    其实要评价一个人,3~5项最关注的指标就可以分出优劣。
    另外,加班我不提倡,正常的工作安排是不应该有加班出现的。
    考核缺陷数量,需要有其他辅助,只算绝对数量会造成考核出来的排名和你心目中的排名差很远。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
     楼主| 发表于 2012-3-16 15:21:49 | 只看该作者
    回复 6# archonwang

    谢谢  archonwang  给的意见,首次写这个东西,看了你的意见才知自己考虑的很不全面。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
     楼主| 发表于 2012-3-16 15:28:05 | 只看该作者
    公司目前考核测试人员,就是以Bug为主来考量,若设计绩效时把Bug数量为辅 这样好吗?
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-21 22:10 , Processed in 0.101966 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表