51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

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

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

[复制链接]

该用户从未签到

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

本帖子中包含更多资源

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

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

使用道具 举报

该用户从未签到

39#
发表于 2007-10-20 22:09:03 | 只看该作者
呵呵,好细呀
回复 支持 反对

使用道具 举报

该用户从未签到

38#
发表于 2007-10-18 17:02:40 | 只看该作者
建议看看有关软件度量的资料.

这个评估的偏差较大.
回复 支持 反对

使用道具 举报

该用户从未签到

37#
发表于 2007-9-20 11:45:47 | 只看该作者
复杂
回复 支持 反对

使用道具 举报

该用户从未签到

36#
发表于 2007-7-30 17:38:09 | 只看该作者
不太认同
1.一个人如何做事,态度
2.做的事的质量
3.测试技术
4.学习能力
5.解决问题的能力
回复 支持 反对

使用道具 举报

该用户从未签到

35#
发表于 2007-7-28 12:10:26 | 只看该作者
原帖由 sanjieyu 于 2007-4-26 11:22 发表



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

很多QA,尤其是经验不足的QA,会为了bug的数量来提交很 ...




你们公司的QA就是QC吗?
回复 支持 反对

使用道具 举报

该用户从未签到

34#
发表于 2007-7-26 16:37:58 | 只看该作者
有难度
回复 支持 反对

使用道具 举报

该用户从未签到

33#
发表于 2007-7-1 17:48:52 | 只看该作者
刚好用上。
回复 支持 反对

使用道具 举报

该用户从未签到

32#
发表于 2007-6-13 11:03:05 | 只看该作者
正好需要,谢谢.
回复 支持 反对

使用道具 举报

该用户从未签到

31#
发表于 2007-6-7 14:07:03 | 只看该作者
这个考核有点复杂,需要有比较细的数据支持.
回复 支持 反对

使用道具 举报

该用户从未签到

30#
发表于 2007-5-22 13:00:25 | 只看该作者
看起来比较理论,说说我们公司的情况,基本上很简单,

1.defects分占60%---我们对每个报上来的defects会有个基础的评分,如果fix了还会加分,duplicate的不给分,考查时对这位tester做一个defects分数统计,这部分分会占绩效的60%。

2.任务分占40%----日常任务的完成情况,知识的共享,培训这部分也采用评分的形式,这部分占40%。


最后得出的分数就是这位tester的绩效
回复 支持 反对

使用道具 举报

该用户从未签到

29#
发表于 2007-5-17 18:22:30 | 只看该作者
评估人不能象评估一条生产线的生产质量
回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2007-5-17 14:35:48 | 只看该作者
sdlkfj4
回复 支持 反对

使用道具 举报

该用户从未签到

27#
发表于 2007-5-15 16:56:19 | 只看该作者
先收下了,看看,谢谢
回复 支持 反对

使用道具 举报

该用户从未签到

26#
发表于 2007-5-10 14:53:31 | 只看该作者

回复 #15 bobli 的帖子

OK
回复 支持 反对

使用道具 举报

该用户从未签到

25#
发表于 2007-5-10 14:52:09 | 只看该作者

回复 #1 coralsong 的帖子

OK
回复 支持 反对

使用道具 举报

该用户从未签到

24#
发表于 2007-4-29 09:46:29 | 只看该作者
我自己很多时候做考核,大的方向不会错,在细节方面就是凭感觉
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2007-4-28 16:02:17 | 只看该作者
小公司弄不来sdlkfj1
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2007-4-28 15:53:58 | 只看该作者
参考一下
回复 支持 反对

使用道具 举报

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

    连续签到: 1 天

    [LV.5]测试团长

    21#
    发表于 2007-4-27 12:54:21 | 只看该作者
    第一感觉:复杂;
    第二感觉:统计数值太细化;


    在公式:∑缺陷数(系统测试)(个) / ∑测试用例文档页数(页)
    参考指标:平均 2.18 个缺陷 / 页

    这个指标用在阶段性总结上还是可行的,拿来考核可能就有点牵强。我的理由是:测试用例发现不了问题并不是测试用例本身的问题,而是和开发人员的素质与用例设计方式存在直接的关系的。要达到这样一种状态,必须保障到测试用例足够的细化。否则前提不明确,做法就值得商榷了。



    总体来讲,这份方案更适合一个大型的团队,团队规模:50人以上的测试人员考核。

    我觉得,测试的成果不仅是可以通过提交的数量来确定的。这些记录的数据表征更多的应该是对项目的整体进度和管理人员对风险的控制程度。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-9-29 04:18 , Processed in 0.093273 second(s), 26 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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