coralsong 2005-12-19 16:54
你们觉得这样的考核方法合理吗？
你们觉得这样的考核方法合理吗？
yongming566 2005-12-27 13:23
谢谢！精辟
云层 2005-12-27 14:56
好像复杂了一点
funly 2005-12-27 16:09
有点怕这种做法.
acer000 2006-1-12 15:35
个人认为考核方法应该根据项目及测试的团队规模，若具规模及测试团队较大的情况下，可以考虑，但很多想法也具有参照性。
另，其实考核这一块儿分析数据的数据收集非常重要，但需要有好的工具及时间、精力、人力，这样详尽的考核若有这些基础，个人感觉挺好的，且具有公正性。
xinwuhan2006 2006-1-24 20:14
先下载了！有空再看！＠相信很有参考价值！谢谢！
非猫 2006-2-10 11:05
这种考核方式从理论上来说是挺好的,实施起来有难度.各项指标的收集是第一个要面对的问题. 另外,参考指标是根据什么来确定的??
lidahench 2006-2-14 16:37
收集相关数据是一项大工程！
lywx_2004 2006-2-16 09:23
好像太复杂了吧。
w阿思 2006-2-17 16:29
有公司是那样做的吗，不太现实
sindy_yao 2006-3-17 14:31
刚刚下载了，有空看看
slide 2006-3-30 21:32
搞得过于复杂了，而且只包含了工作的基本内容，对于个人的学习、技术的交流和积累、测试工具的开发和维护、部门的建设等等都没有涉及到。不是一个全面的考核，更适用于工作内容相对简单、固定的测试工人，而不是测试工程师。
其实，最简单直观的考核指标的是提交故障数量，可以直接体现测试工作质量，而且便于统计。
其他指标可以根据自己工作的特点进行添加，工作越细致，要考核的内容就越细致。
关于考核的内容，可以看看关于平衡计分卡的书，比较全面。
冰河 2006-3-31 11:33
好像更适合于测试人员在50人之上的测试团体。
太过于细化，太拘泥于形式。
atce 2006-3-31 15:02
关于测试设计部分，有没有考虑过加入测试用例有效率，包括∑缺陷数（产品发布后用户反馈）。
bobli 2006-4-2 17:11
发一个给大家参考一下
coolsam 2006-9-23 12:16
都是公式，不过实际用起来可能会好很多，支持一下
jkdragon 2007-4-12 22:26
不同的公司还是有不同的情况呀
zmf111 2007-4-16 10:12
有点怕这种做法.
sunkitty 2007-4-22 21:42
最烦考核了！
sanjieyu 2007-4-26 11:22
[quote]原帖由 [i]slide[/i] 于 2006-3-30 21:32 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=201960&ptid=23270][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
其实，最简单直观的考核指标的是提交故障数量，可以直接体现测试工作质量，而且便于统计 ... [/quote]
这样的做法是很危险的,我以前呆过的两家外企,应该算是国内做测试很有名的两家外企了,也采用过这种方式来评估QA的绩效,结果容易导致的一个问题就是
很多QA,尤其是经验不足的QA,会为了bug的数量来提交很多没用的,或者是重复的bug,这样直接导致开发对QA的抱怨,不信任和降低测试效率.
其实问题也好解决
不仅要看提交的bug数量,更重要的是要看QA提交的bug,开发能fix的比例.从如下几个方面评估也许更好一点
1 QA提交的bug数量
2 开发 fix掉的bug的数量
3 Duplicate,不能重现,不是bug的这些bug 数量的比例
archonwang 2007-4-27 12:54
第一感觉：复杂；
第二感觉：统计数值太细化；
在公式：∑缺陷数（系统测试）（个） / ∑测试用例文档页数（页）
参考指标：平均 2.18 个缺陷 / 页
这个指标用在阶段性总结上还是可行的，拿来考核可能就有点牵强。我的理由是：测试用例发现不了问题并不是测试用例本身的问题，而是和开发人员的素质与用例设计方式存在直接的关系的。要达到这样一种状态，必须保障到测试用例足够的细化。否则前提不明确，做法就值得商榷了。
总体来讲，这份方案更适合一个大型的团队，团队规模：50人以上的测试人员考核。
我觉得，测试的成果不仅是可以通过提交的数量来确定的。这些记录的数据表征更多的应该是对项目的整体进度和管理人员对风险的控制程度。
紫慕 2007-4-28 16:02
小公司弄不来sdlkfj1
binary 2007-4-29 09:46
我自己很多时候做考核，大的方向不会错，在细节方面就是凭感觉
yuanxinyi16rain 2007-5-10 14:52
回复 #1 coralsong 的帖子
OK
yuanxinyi16rain 2007-5-10 14:53
回复 #15 bobli 的帖子
OK
解放军 2007-5-15 16:56
先收下了，看看，谢谢
pigface 2007-5-17 14:35
sdlkfj4
EricJiang 2007-5-17 18:22
评估人不能象评估一条生产线的生产质量
ryewhisky 2007-5-22 13:00
看起来比较理论，说说我们公司的情况，基本上很简单，
1.defects分占60％－－－我们对每个报上来的defects会有个基础的评分，如果fix了还会加分，duplicate的不给分，考查时对这位tester做一个defects分数统计，这部分分会占绩效的60%。
2.任务分占40%－－－－日常任务的完成情况，知识的共享，培训这部分也采用评分的形式，这部分占40%。
最后得出的分数就是这位tester的绩效
toyfrog 2007-6-7 14:07
这个考核有点复杂,需要有比较细的数据支持.
里米特 2007-6-13 11:03
正好需要,谢谢.
crystalpear 2007-7-1 17:48
刚好用上。
tanzj204 2007-7-26 16:37
有难度
oracletest 2007-7-28 12:10
[quote]原帖由 [i]sanjieyu[/i] 于 2007-4-26 11:22 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=501936&ptid=23270][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
这样的做法是很危险的,我以前呆过的两家外企,应该算是国内做测试很有名的两家外企了,也采用过这种方式来评估QA的绩效,结果容易导致的一个问题就是
很多QA,尤其是经验不足的QA,会为了bug的数量来提交很 ... [/quote]
你们公司的QA就是QC吗？
langchaogc 2007-7-30 17:38
不太认同
1.一个人如何做事，态度
2.做的事的质量
3.测试技术
4.学习能力
5.解决问题的能力
pbulic 2007-10-18 17:02
建议看看有关软件度量的资料.
这个评估的偏差较大.
tessss 2007-10-20 22:09
呵呵，好细呀
页:
[1]