51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 10548|回复: 38
打印 上一主题 下一主题

[原创] 你们觉得这样的考核方法合理吗?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2005-12-19 16:54:00 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
你们觉得这样的考核方法合理吗?

本帖子中包含更多资源

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

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

使用道具 举报

  • TA的每日心情
    郁闷
    2014-11-5 22:10
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    2#
    发表于 2005-12-27 13:23:41 | 只看该作者
    谢谢!精辟
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2005-12-27 14:56:41 | 只看该作者
    好像复杂了一点
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2005-12-27 16:09:17 | 只看该作者
    有点怕这种做法.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2006-1-12 15:35:42 | 只看该作者
    个人认为考核方法应该根据项目及测试的团队规模,若具规模及测试团队较大的情况下,可以考虑,但很多想法也具有参照性。
    另,其实考核这一块儿分析数据的数据收集非常重要,但需要有好的工具及时间、精力、人力,这样详尽的考核若有这些基础,个人感觉挺好的,且具有公正性。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2006-1-24 20:14:55 | 只看该作者
    先下载了!有空再看!@相信很有参考价值!谢谢!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2006-2-10 11:05:43 | 只看该作者
    这种考核方式从理论上来说是挺好的,实施起来有难度.各项指标的收集是第一个要面对的问题. 另外,参考指标是根据什么来确定的??
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2006-2-14 16:37:45 | 只看该作者
    收集相关数据是一项大工程!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2006-2-16 09:23:28 | 只看该作者
    好像太复杂了吧。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2006-2-17 16:29:19 | 只看该作者
    有公司是那样做的吗,不太现实
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2006-3-17 14:31:17 | 只看该作者
    刚刚下载了,有空看看
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2006-3-30 21:32:13 | 只看该作者
    搞得过于复杂了,而且只包含了工作的基本内容,对于个人的学习、技术的交流和积累、测试工具的开发和维护、部门的建设等等都没有涉及到。不是一个全面的考核,更适用于工作内容相对简单、固定的测试工人,而不是测试工程师。
    其实,最简单直观的考核指标的是提交故障数量,可以直接体现测试工作质量,而且便于统计。
    其他指标可以根据自己工作的特点进行添加,工作越细致,要考核的内容就越细致。
    关于考核的内容,可以看看关于平衡计分卡的书,比较全面。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2006-3-31 11:33:09 | 只看该作者
    好像更适合于测试人员在50人之上的测试团体。
    太过于细化,太拘泥于形式。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2006-3-31 15:02:14 | 只看该作者
    关于测试设计部分,有没有考虑过加入测试用例有效率,包括∑缺陷数(产品发布后用户反馈)。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2006-4-2 17:11:43 | 只看该作者

    发一个给大家参考一下

    本帖子中包含更多资源

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

    x
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2006-9-23 12:16:46 | 只看该作者
    都是公式,不过实际用起来可能会好很多,支持一下
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2007-4-12 22:26:54 | 只看该作者
    不同的公司还是有不同的情况呀
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2007-4-16 10:12:07 | 只看该作者
    有点怕这种做法.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2007-4-22 21:42:35 | 只看该作者
    最烦考核了!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2007-4-26 11:22:08 | 只看该作者
    原帖由 slide 于 2006-3-30 21:32 发表
    其实,最简单直观的考核指标的是提交故障数量,可以直接体现测试工作质量,而且便于统计 ...



    这样的做法是很危险的,我以前呆过的两家外企,应该算是国内做测试很有名的两家外企了,也采用过这种方式来评估QA的绩效,结果容易导致的一个问题就是

    很多QA,尤其是经验不足的QA,会为了bug的数量来提交很多没用的,或者是重复的bug,这样直接导致开发对QA的抱怨,不信任和降低测试效率.

    其实问题也好解决

    不仅要看提交的bug数量,更重要的是要看QA提交的bug,开发能fix的比例.从如下几个方面评估也许更好一点

    1 QA提交的bug数量
    2 开发 fix掉的bug的数量
    3 Duplicate,不能重现,不是bug的这些bug 数量的比例
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-9-29 02:17 , Processed in 0.083997 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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