测试团队的绩效考核
来源:互联网 发布:mac战网怎么更改地区 编辑:程序博客网 时间:2024/04/28 00:36
目前很多软件公司,即使有绩效考核机制,由于内容比较粗(例如,开发与测试用一个绩效考核机制),不同岗位很难评价到位。
其实,做好员工的绩效考核,不仅是对员工的客观评价,而且还能起很好的总结作用:让员工清晰自己哪方面做得好,哪方面需要改进,更好地进行接下来的工作。
在公司没有提供有效的绩效考核机制,或则根本没有绩效考核机制的情况下,制定符合测试人员的绩效考核机制,是比较必要的。由于测试人员与开发人员的工作内容不一致,测试人员必须按照测试人员的特性进行设置。
参考了网上的一些经验,初定以下绩效考核机制:
1. 测试计划
2.测试用例设计
3.测试用例评审
4.测试过程
5.测试报告
其实,做好员工的绩效考核,不仅是对员工的客观评价,而且还能起很好的总结作用:让员工清晰自己哪方面做得好,哪方面需要改进,更好地进行接下来的工作。
在公司没有提供有效的绩效考核机制,或则根本没有绩效考核机制的情况下,制定符合测试人员的绩效考核机制,是比较必要的。由于测试人员与开发人员的工作内容不一致,测试人员必须按照测试人员的特性进行设置。
参考了网上的一些经验,初定以下绩效考核机制:
1. 测试计划
不合格
合格
优秀
1, 没有按时完成;
2, 没有按照测试计划规范标准编写;
3, 描述不清晰;
4, 描述有误
2, 没有按照测试计划规范标准编写;
3, 描述不清晰;
4, 描述有误
1, 按时完成;
2, 按照测试计划规范标准编写;
3, 描述基本清晰;
4, 描述基本无误;
5, 测试过程中,能及时更新测试计划
2, 按照测试计划规范标准编写;
3, 描述基本清晰;
4, 描述基本无误;
5, 测试过程中,能及时更新测试计划
1, 基于‘合格’之上;
2, 描述清晰,内容正确;
3, 测试能完全按照测试计划,顺利进行
2, 描述清晰,内容正确;
3, 测试能完全按照测试计划,顺利进行
2.测试用例设计
不合格
合格
优秀
1, 没有按时完成;
2, 没有按照用例规范标准编写;
3, 没有按照SRS设计用例;
4, 有遗漏;
5, 用例评审,用例描述不够清晰/有误,需要修改的用例率>5%
2, 没有按照用例规范标准编写;
3, 没有按照SRS设计用例;
4, 有遗漏;
5, 用例评审,用例描述不够清晰/有误,需要修改的用例率>5%
1, 按时完成;
2, 按照用例规范标准编写;
3, 基本按照SRS设计用例;
4, 没有遗漏;
5, 用例评审,用例描述比较清晰,需要修改的用例率<5%
2, 按照用例规范标准编写;
3, 基本按照SRS设计用例;
4, 没有遗漏;
5, 用例评审,用例描述比较清晰,需要修改的用例率<5%
1, 基于‘合格’之上;
2, 用例评审,没有需要修改的用例;
3, 对一些比较特殊的测试用例总结,及时进行分享,有效提高测试人员的测试用例设计能力
2, 用例评审,没有需要修改的用例;
3, 对一些比较特殊的测试用例总结,及时进行分享,有效提高测试人员的测试用例设计能力
3.测试用例评审
不合格
合格
优秀
1, 没有按时完成;
2, 没找到没有按照用例规范标准编写;
3, 没找到没有按照SRS设计用例;
4, 没找到测试用例有遗漏;
5, 用例描述不够清晰/有误,没发现的占>5%
2, 没找到没有按照用例规范标准编写;
3, 没找到没有按照SRS设计用例;
4, 没找到测试用例有遗漏;
5, 用例描述不够清晰/有误,没发现的占>5%
1, 按时完成;
2, 全部找到没有按照用例规范标准编写的地方;
3, 全部找到没有按照SRS思路设计用例;
4, 全部找到测试用例的遗漏;
5, 用例描述不够清晰/有误,没发现的占<5%
2, 全部找到没有按照用例规范标准编写的地方;
3, 全部找到没有按照SRS思路设计用例;
4, 全部找到测试用例的遗漏;
5, 用例描述不够清晰/有误,没发现的占<5%
1, 基于‘合格’之上;
2, 用例描述不够清晰/有误,全部找到;
3, 总结测试用例写得好与不好的地方,及时分享,有效提高测试人员的测试用例设计能力
2, 用例描述不够清晰/有误,全部找到;
3, 总结测试用例写得好与不好的地方,及时分享,有效提高测试人员的测试用例设计能力
4.测试过程
不合格
合格
优秀
1, 没有按时完成测试;
2, 没有按照测试用例一步一步进行测试;
3, 严重的缺陷没有找到;
4, 没有及时提交发现的缺陷;
5, 缺陷描述不清晰/不正确;
6, 没有配合开发进行缺陷修复;
7, 无效的缺陷率>5%;
8, 重复的缺陷率>5%
2, 没有按照测试用例一步一步进行测试;
3, 严重的缺陷没有找到;
4, 没有及时提交发现的缺陷;
5, 缺陷描述不清晰/不正确;
6, 没有配合开发进行缺陷修复;
7, 无效的缺陷率>5%;
8, 重复的缺陷率>5%
1, 按时完成测试;
2, 按照测试用例一步一步进行测试;
3, 及时提交发现的缺陷;
4, 缺陷描述基本清晰/基本正确,开发人员经过少量询问后能基本定位缺陷;
5, 基本配合开发进行缺陷修复;
6, 无效的缺陷率<5%;
7, 重复的缺陷率<5%
2, 按照测试用例一步一步进行测试;
3, 及时提交发现的缺陷;
4, 缺陷描述基本清晰/基本正确,开发人员经过少量询问后能基本定位缺陷;
5, 基本配合开发进行缺陷修复;
6, 无效的缺陷率<5%;
7, 重复的缺陷率<5%
1, 基于‘合格’之上;
2, 描述清晰/正确,开发人员无须经过询问定位缺陷;
3, 主动配合开发进行缺陷修复;
4, 没有无效的缺陷;
5, 没有重复的缺陷;
6, 测试结束后,能总结及时进行分享,有效提高测试人员的测试能力
2, 描述清晰/正确,开发人员无须经过询问定位缺陷;
3, 主动配合开发进行缺陷修复;
4, 没有无效的缺陷;
5, 没有重复的缺陷;
6, 测试结束后,能总结及时进行分享,有效提高测试人员的测试能力
5.测试报告
不合格
合格
优秀
1, 没有按时完成;
2, 没有按照实际情况编写;
3, 内容描述不清晰/准确
2, 没有按照实际情况编写;
3, 内容描述不清晰/准确
1, 按时完成;
2, 基本按照实际情况编写;
3, 内容描述基本清晰/准确
2, 基本按照实际情况编写;
3, 内容描述基本清晰/准确
1, 基于‘合格’之上;
2, 内容描述清晰/准确,有效协助开发分析所发现的问题
2, 内容描述清晰/准确,有效协助开发分析所发现的问题
- 测试团队的绩效考核
- 测试团队如何进行绩效考核
- 关于测试的绩效考核
- 测试人员眼中的绩效考核测试人员眼中的绩效考核
- 关于软件测试人员绩效考核的讨论
- 关于软件测试人员绩效考核的讨论
- 关于软件测试人员绩效考核的讨论
- 测试人员的绩效考核应该如何开展?
- [一分钟先生]袁斌:研发团队的绩效考核方式
- 敏捷团队如何进行绩效考核?
- 小型软件公司的绩效考核
- 小型软件公司的绩效考核
- 小型软件公司的绩效考核
- 小型软件公司的绩效考核
- 小型软件公司的绩效考核
- 研发人员的绩效考核
- 谈谈程序员的绩效考核
- 研发绩效考核的谬误
- 基于SaaS的呼叫中心应用思考
- CAN总线的物理接口特性是基于RS485还是RS232?
- WindowsXP上使用FileZilla的 SFTP 功能传输文件
- linux文件权限chmod
- 进程间通信-信号
- 测试团队的绩效考核
- wordpress 的用户登录机制简易分析
- 奇偶数分离
- Android应用程序资源的编译和打包过程分析
- 使用GoogleCode SVN服务
- 内核编译错误的一些解决办法
- opencv例程之哈夫直线变换
- EF 4.3 Code-Based Migrations Walkthrough
- UNICODE 截取字符长度的方法