软件测试工程师绩效评估表.doc
- 文档编号:188707
- 上传时间:2022-10-05
- 格式:DOC
- 页数:8
- 大小:99KB
软件测试工程师绩效评估表.doc
《软件测试工程师绩效评估表.doc》由会员分享,可在线阅读,更多相关《软件测试工程师绩效评估表.doc(8页珍藏版)》请在冰豆网上搜索。
软件测试工程师绩效评估表
一.软件测试工程师职责:
1与软件产品部配合完成软件需求分析讨论,并根据需求说明书制定《项目测试(计划)方案》;编写《测试用例》;建立测试环境;
2负责研发部门各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改软件的模块测试和系统测试;建立、推广并维护实施软件版本管理系统;
3负责推广实施软件开发文档规范化工作,管理研发产品相关文档;
4负责配合软件研发部门等对于新项目软件或修改升级项目软件的测试工作,并提供测试报告;
5负责监督软件开发流程的执行,并负责提出软件开发过程改进建议,提高软件产品质量。
6与开发工程师和研发部门交流报告任务进展情况,并提出最近的测试需求;
7测试部负责制订测试计划、测试用例和测试实施方案,项目主负责人安排测试与对应的开发人员交流完成测试执行工作;及时提交准确、完整的《项目测试报告》;
8项目主负责人负责开发流程管理和人力资源、测试用软硬件资源调配,需要与研发之外的部门定期交流掌握下周或近期可能测试任务;
9外部接口都由测试部主管负责完成,与其他项目组和产品部门协调项目进度;
二.软件测试的不确定性:
1软件测试的目的就是使软件的错误不断趋进于零,但软件的错误是永远找不完的;
2开始测试时,可能软件使用1个小时就出现10个错误;测试修正后1个小时出现一个错误,继续修正,继续测试,直到约一个月出现一个错误。
这时这个出错几率已经通过终结评审可以接受了。
那么测试就结束了。
移植成功之后测试工作由开发部门来维护。
3测试一些成熟的游戏或应用,测试过程中很难发现大量的缺陷;而测试一些不成熟的游戏或应用,在测试前期,会出现大量的问题;这样就导致不同的工程师发现不同数量的bug;
4软件测试的进度首先会按照测试计划逐步进行,但是在测试过程中,测试进度会随研发部门的进度而调整;所以积极的与研发部门交流、协调测试中的问题是相当必要的。
三.测试工作最低成功标准及测试工程师考核内容:
测试工作的最终目标就是发现客户可能发现的所有错误。
如果移植测试在使用第一天就发现了你没测试出来的错误,那测试是失败的。
如果使用了很久(如几个月)才出现错误,那说明测试还是成功的。
测试工程师考核内容:
1测试工程师比开发工程师更了解产品;(产品各模块总体把握能力)
2测试工程师能从客户的角度来检测软件的功能;(用户身份)
3测试工程师获取资料,使得编制的测试用例更切合测试的重点、难点以及关注点;
(编写测试用例)
4测试工程师比开发工程师更容易发现产品的问题;(不同的思维模式)
5测试工程师总是不断的发现问题,验证问题;(提交bug数量、bug质量)
6测试工程师按照测试计划完成各自工作;(测试计划的执行能力)
7测试工程师以操作员的角度测试产品;(Free测试能力)
8测试工程师及时与开发工程师沟通、交流解决问题;(部门间的工作协调能力)
9测试工程师及时提交测试报告;(报告的及时性、准确性)
10测试工程师之间处理问题;(共同完成任务)
11测试工程师协助开发工程师,了解开发流程等信息;(学习能力)
四.软件测试人员工作业绩评估的误区:
1不能仅从提交的问题数量、测试执行用例数量来判断测试人员的好坏;
模块A很不稳定,潜在的问题数可能有100个,由测试人员甲负责测试,他一个月执行300个用例,提交50个问题单,发现30个有效问题,有10个严重问题;
模块B比较稳定,潜在的问题数可能有20个,由测试人员乙负责测试,他一个月执行100个用例,提交20个问题单,发现18个有效问题,有8个严重问题;
从上述测试执行结果来看,甲提交的问题单数量和执行用例数量都要远远高于乙,但是从测试的质量来看,模块B的遗留问题显然少于模块A,甲执行测试的充分性显然不如乙,从问题单质量来看,甲提交的问题单虽然很多,但近半数是非问题,做了无用功,还影响到开发人员对问题的定位所消耗的时间。
因此,必须要走出用问题单数量、用例数量评价测试人员的误区。
2对软件人员发现的问题的价值没有进行评估;
发现一个系统架构设计方面的缺陷和隐患远比发现几个普通界面显示问题的价值大的多;
3不重视测试文档的质量;
测试文档的质量往往是测试人员测试水平的反映;只有对系统进行了统分的、深入的测试人员才能写出高质量的测试报告;
4不重视测试人员的综合能力;
责任心、积极性、创造性以及沟通和协调能力
附:
软件测试工程师业绩评估模板:
(满分:
100分)
软件测试工程师业绩评估模板:
(满分:
100分)
类型
评定参数
参数值
说明
问题
(35%)
提交有效问题数量
单位(个)
最基本的考核指标
提交的非问题数量
单位(个)
需要测试人员意识到处理非问题影响测试、开发的工作效率;测试主管必须严格审核测试人员提交的bug
提交问题的规范性
优秀
良好
普通
不合格
问题描述是否清晰;
相关trace文件是否齐全;
问题等级、版本等信息是否正确;
问题跟踪是否到位;
严重问题所占比例
单位(%)
(严重问题/问题总数)*100%
提交问题的质量
非常好
很好
一般
良好
低
综合评定测试人员提交问题的质量;
测试人员发现问题的深入程度;
工作效率
提交bug
验证bug
优秀
良好
普通
不合格
对自己所提交问题的多版本跟踪;
Check他人bug的程度;
不同模块功能的理解程度;
测试用例
(20%)
执行用例
覆盖率
开发用例难度
困难
普通
容易
编写测试用例质量
….
用力的难度直接反映测试人员的测试能力;并影响测试效率;
FREETEST
….
用例外,测试发现问题的能力
新增测试用例价值
….
新增测试用例质量
….
文档
(15%)
测试报告质量
优秀
良好
普通
不合格
测试报告的规范化程度;
及时性;
准确性;
内部测试文档、测试经验的交流及共享
经常
偶尔
从不
测试工作的协调;
经验的交流;
问题的确定;
等等
态度
(30%)
工作积极性
优良中差
主动解决测试中遇到的问题;
沟通能力
…
根据实际情况,分析评价;
学习能力
…
不断的提高工作效率;
项目了解(主动性)
…
对项目总体的把握;
测试计划的执行
…
执行计划;
部门间团结协作
…
各部门相互配合解决问题;
上级主管综合评定及意见:
综合评定:
部门经理给出测试人员考核评定及意见
附:
软件测试工程师业绩评估模板
评估类型
绩效指标
评价标准
分值
备注
评分等级
分值
激励方式
软件测试绩效
工作态度
严格遵守各项工作制度和岗位要求。
工作认真负责,责任心强。
能够主动进行工作沟通、交流。
主动发现问题,并且跟踪解决。
积极参与测试组各项活动,能够主动承担组内工作。
16-20分
1、工作制度遵循性(公司考勤制度、岗位职责)
2、工作认真性、责任心
3、工作积极性
4、沟通、交流
5、主动性、参与性
A
59~70
基本奖励2倍金额
遵守各项工作制度和岗位要求。
工作认真负责,责任心强。
能够主动进行工作沟通、交流。
主动发现问题,基本能做到跟踪解决。
参与测试组各项活动,能够承担组内工作任务。
11-15分
B
40~54
基本奖励
遵守各项工作制度和岗位要求。
工作认真负责,责任心强。
能够进行工作中基本沟通、交流。
发现问题,缺少跟踪解决。
参与测试组各项活动,能够承担组内工作。
6-10分
C
21~35
提出改进
有督导情况下
基本能遵守各项工作制度和岗位要求。
能基本按要求完成任务。
进行基本工作沟通、交流。
发现问题,缺少跟踪解决。
基本能参与测试组各项活动,不能够承担组内工作。
0-5分
D
0~16
警告,如果导致影响工作进度、影响上线产品质量根据影响程度给予一定金额处罚。
测试用例
严格按照用例模版编写用例
根据需求设计有效用例,覆盖所有的需求点。
用例描述准确、简洁、清晰,评审通过率高。
按计划执行用例并且能够及时补充用例保证用例完整性,对于无法执行或不具备环境不能法执行用例及时沟通,并且测试结果中具体说明。
9-10分
1、测试用例规范性
2、设计有效性(覆盖率)
3、用例描述的准确性
4、用例评审通过率
5、用例执行有效性(是否按计划执行)
6、用例及时性、准确性、完整性
能够按照用例模版编写用例
根据需求设计有效用例,基本覆盖所有的需求点。
用例描述比较准确、简洁、清晰,评审通过率高。
按计划执行用例并且能够及时补充用例保证用例完整性,对于无法执行或不具备环境不能执行用例及时沟通。
并且测试结果中具体说明。
6-8分
在有人员指导情况下达到以下标准或者个人独立工作达到以下要求
能够按照用例模版编写用例
根据需求设计有效用例,基本覆盖主要功能的需求点。
用例描述基本准确、简洁、清晰,通过评审可以达到要求。
基本按计划执行用例并且基本能及时补充用例保证用例完整性。
对于无法执行或不具备环境不能执行用例基本做到及时沟通,并且测试结果中具体说明。
3-5分
基本能按照用例模版编写用例
根据需求设计有效用例,没有覆盖所有的需求点。
用例描述基本准确、简洁、清晰,通过评审可以达到要求。
不能按计划执行用例并且能够及时补充用例保证用例完整性。
对于无法执行或不具备环境不能执行用例基本做到及时沟通
0-2分
测试BUG
能够按照规定的流程提交并跟踪BUG的全过程。
BUG描述语言简洁、准确。
BUG再现步骤清晰、条理性强,易于再现。
依据需求提交相应BUG,没提交错误BUG。
能够分析和定位产生的原因,并能根据BUG的产生趋势做出有效的质量和风险风析
9-10分
1、bug规范(1、描述2、bug和用例相对应)
2、bug描述准确性
3、重显性
4、bug有效性
5、bug总结分析能力
能够按照规定的流程提交并跟踪BUG的全过程。
BUG描述语言较简洁、较准确。
BUG再现步骤较清晰、条理性较强,易于再现。
依据需求提交相应BUG,很少提交错误BUG。
能够完成基本分析和定位产生的原因,基本并能根据BUG的产生趋势做出有效的质量和风险风析。
6-8分
在有人员指导情况下达到以下标准或者个人独立工作达到以下要求:
基本能够按照规定的流程提交并跟踪BUG的全过程。
BUG描述语言基本完整。
BUG再现步骤基本清晰、条理性不强,可以再现。
依据需求提交相应BUG,出现提交错误BUG。
能够协助开发再现,定位bug。
对bug进行基本总结。
3-5分
能够按照规定的流程提交并跟踪BUG的全过程。
提交的BUG有三分之一描述语言不准确。
BUG有三分之一出现步骤不清晰、条理性差,难于再现。
依据需求基本能提交相应BUG,出现错误BUG。
0-2分
工作能力
能够按时或提前完成工作计划,并且内容有效、准确、合理,使人能清楚地把握工作进展和动态。
能够按时或提前完成任务,并且按要求完成各项分配的工作,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 工程师 绩效 评估
![提示](https://static.bdocx.com/images/bang_tan.gif)