51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: szxutao
打印 上一主题 下一主题

[资料] 测试人员绩效评价方法----仅供参考

[复制链接]

该用户从未签到

41#
发表于 2006-8-10 18:10:16 | 只看该作者
为什么我的附件就是下不了
谁能告诉我附件要多少分数才能下载啊
回复 支持 反对

使用道具 举报

该用户从未签到

42#
发表于 2006-8-16 05:16:52 | 只看该作者
没资格评论还。先看看。
回复 支持 反对

使用道具 举报

该用户从未签到

43#
发表于 2006-8-18 11:43:47 | 只看该作者
和测试有关的东西都该知道
回复 支持 反对

使用道具 举报

该用户从未签到

44#
发表于 2006-8-30 17:18:02 | 只看该作者
路在何方
回复 支持 反对

使用道具 举报

该用户从未签到

45#
发表于 2006-9-6 13:05:18 | 只看该作者
楼主的这份的测试人员绩效考评以bug的数量和质量为评估主要标准,的确可以在一定程度上反映测试人员的工作情况。

但是长期使用会有产生一定的负面影响。比如,假设我是一名测试人员,在项目初期,我发现需求中存在一个业务层面的问题,而且清楚这个将来一定会成为一个比较严重的bug。那么,我是不是应该在这时向项目组反映这个问题呢??按照楼主的考评标准,我这时反映问题对自己基本毫无好处。这个评估设计文档的时候也会发现(比如transaction完整性,性能等问题)

单从考评文档来看,主要问题是把测试工作列在开发之后,宗所周知,测试应该从项目开始就介入,通过对需求文档、开发设计文档的评估,为开发人员,需求人员,项目经理提供服务。那么对测试人员的评估就决不局限于bug的数量和质量上面。

另外,测试人员report bug的能力也是十分关键,不仅要清楚明白,而且正确定位bug的影响范围。只有你的report正确,项目经理才能正确决定是否有必要fix bug。
回复 支持 反对

使用道具 举报

该用户从未签到

46#
发表于 2006-9-8 10:40:18 | 只看该作者
藏着先,稍后再学习~~`
回复 支持 反对

使用道具 举报

该用户从未签到

47#
发表于 2006-9-10 01:30:59 | 只看该作者
测试管理说到底也是艺术,而不是简单的量化考核。如果什么事情都可以简单衡量的化,任何人都可以做领导了。

事实上,我们确实需要一个量化。只是比较难而已。

如果觉得bug的数量来考核测试人员不妥的话,那我们就应该想更加妥当的方法。

毕竟这是需要个过程的。
回复 支持 反对

使用道具 举报

该用户从未签到

48#
发表于 2006-10-14 18:38:54 | 只看该作者
仅仅可以参考,衡量的范围还是很全面的。
回复 支持 反对

使用道具 举报

该用户从未签到

49#
发表于 2006-10-19 16:02:00 | 只看该作者
写的不错,不过就我所知目前大部分单位仍是人为主观进行绩效评估的! 如按以上方法来执行估计还是比较有难度的哦!
   新手上路---以上是自己的浅见,以后还望大家多多指点!!!
回复 支持 反对

使用道具 举报

该用户从未签到

50#
发表于 2006-12-12 11:26:38 | 只看该作者
赞成#39 楼的看法!
回复 支持 反对

使用道具 举报

该用户从未签到

51#
发表于 2007-1-9 16:08:14 | 只看该作者
收藏!
回复 支持 反对

使用道具 举报

该用户从未签到

52#
发表于 2007-1-22 17:43:01 | 只看该作者
哎,难啊,最好就是找到一个问题能奖励多少钱,那就舒服了
回复 支持 反对

使用道具 举报

  • TA的每日心情
    慵懒
    2019-8-13 14:26
  • 签到天数: 75 天

    连续签到: 1 天

    [LV.6]测试旅长

    53#
    发表于 2007-3-8 16:13:44 | 只看该作者
    呵呵,测试新手,可以通过这个来测试自己是否合格
    我试试先
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    54#
    发表于 2007-4-3 14:49:31 | 只看该作者
    这篇文档还是有一定的参考性的~
    目前还有一个问题就是对测试用例的评判怎么样才有一个比较好的标准,因为大多数情况下可能没有太多的时间来写测试用例~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    55#
    发表于 2007-4-19 17:14:07 | 只看该作者

    回复 #4 piao_lingcao 的帖子

    bug管理工具你只需要会一个就OK了!其他的工具是相通的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    56#
    发表于 2007-4-20 09:29:11 | 只看该作者
    一直就想不明白,测试人员的绩效应怎样评价.
    用BUG的数量与严重程序来评价总觉得问题太大.
    A和B两个测试员,A的水平好一些,在安排工作时会先安排B做功能的一般性测试,之后再由A接手去做可靠性、容错性这样的测试.
    这样去查看每天提交的BUG,B一直都比A提交的多的多,B提交的严重级别的BUG也不会比A的少呀,测试组几个人,每个人的工作不同,怎样去评价每个人的绩效?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    57#
    发表于 2007-4-21 17:07:47 | 只看该作者
    呵呵 讨论的不错 我暂时站反方
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    58#
    发表于 2007-4-24 09:17:50 | 只看该作者

    回复 #1 szxutao 的帖子

    OK
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    59#
    发表于 2007-4-24 11:01:59 | 只看该作者

    你的考核方法

    大侠,感觉的你的考核方法是拍脑袋出来的,考核起来不容易.能不能量化一点呢.
    另外,我们产品/项目的最终目的是满足客户需求,我们其实可以把这方面也考虑到考核方法里去:已发布软件(已经测试)出现重大问题、已发布软件重现之前发现的错误。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    60#
    发表于 2007-4-28 17:44:43 | 只看该作者
    sdlkfj2
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-21 21:37 , Processed in 0.079875 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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