目前很多软件公司,即使有绩效考核机制,由于内容比较粗(例如,开发与测试用一个绩效考核机制),不同岗位很难评价到位。
其实,做好员工的绩效考核,不仅是对员工的客观评价,而且还能起很好的总结作用:让员工清晰自己哪方面做得好,哪方面需要改进,更好地进行接下来的工作。
在公司没有提供有效的绩效考核机制,或则根本没有绩效考核机制的情况下,制定符合测试人员的绩效考核机制,是比较必要的。由于测试人员与开发人员的工作内容不一致,测试人员必须按照测试人员的特性进行设置。
参考了网上的一些经验,初定以下绩效考核机制:
1 . 测试计划
2 .测试用例设计
3 .测试用例评审
4 .测试过程
5 .测试报告
其实,做好员工的绩效考核,不仅是对员工的客观评价,而且还能起很好的总结作用:让员工清晰自己哪方面做得好,哪方面需要改进,更好地进行接下来的工作。
在公司没有提供有效的绩效考核机制,或则根本没有绩效考核机制的情况下,制定符合测试人员的绩效考核机制,是比较必要的。由于测试人员与开发人员的工作内容不一致,测试人员必须按照测试人员的特性进行设置。
参考了网上的一些经验,初定以下绩效考核机制:
1 . 测试计划
不合格
|
合格
|
优秀
|
1, 没有按时完成;
2, 没有按照测试计划规范标准编写; 3, 描述不清晰; 4, 描述有误 |
1, 按时完成;
2, 按照测试计划规范标准编写; 3, 描述基本清晰; 4, 描述基本无误; 5, 测试过程中,能及时更新测试计划 |
1, 基于‘合格’之上;
2, 描述清晰,内容正确; 3, 测试能完全按照测试计划,顺利进行 |
2 .测试用例设计
不合格
|
合格
|
优秀
|
1, 没有按时完成;
2, 没有按照用例规范标准编写; 3, 没有按照 SRS 设计用例; 4, 有遗漏; 5, 用例评审,用例描述不够清晰 / 有误,需要修改的用例率 >5% |
1, 按时完成;
2, 按照用例规范标准编写; 3, 基本按照 SRS 设计用例; 4, 没有遗漏; 5, 用例评审,用例描述比较清晰,需要修改的用例率 <5% |
1, 基于‘合格’之上;
2, 用例评审,没有需要修改的用例; 3, 对一些比较特殊的测试用例总结,及时进行分享,有效提高测试人员的测试用例设计能力 |
3 .测试用例评审
不合格
|
合格
|
优秀
|
1, 没有按时完成;
2, 没找到没有按照用例规范标准编写; 3, 没找到没有按照 SRS 设计用例; 4, 没找到测试用例有遗漏; 5, 用例描述不够清晰 / 有误,没发现的占 >5% |
1, 按时完成;
2, 全部找到没有按照用例规范标准编写的地方; 3, 全部找到没有按照 SRS 思路设计用例; 4, 全部找到测试用例的遗漏; 5, 用例描述不够清晰 / 有误,没发现的占 <5% |
1, 基于‘合格’之上;
2, 用例描述不够清晰 / 有误,全部找到; 3, 总结测试用例写得好与不好的地方,及时分享,有效提高测试人员的测试用例设计能力 |
4 .测试过程
不合格
|
合格
|
优秀
|
1, 没有按时完成测试;
2, 没有按照测试用例一步一步进行测试; 3, 严重的缺陷没有找到; 4, 没有及时提交发现的缺陷; 5, 缺陷描述不清晰 / 不正确; 6, 没有配合开发进行缺陷修复; 7, 无效的缺陷率 >5% ; 8, 重复的缺陷率 >5% |
1, 按时完成测试;
2, 按照测试用例一步一步进行测试; 3, 及时提交发现的缺陷; 4, 缺陷描述基本清晰 / 基本正确,开发人员经过少量询问后能基本定位缺陷; 5, 基本配合开发进行缺陷修复; 6, 无效的缺陷率 <5% ; 7, 重复的缺陷率 <5% |
1, 基于‘合格’之上;
2, 描述清晰 / 正确,开发人员无须经过询问定位缺陷; 3, 主动配合开发进行缺陷修复; 4, 没有无效的缺陷; 5, 没有重复的缺陷; 6, 测试结束后,能总结及时进行分享,有效提高测试人员的测试能力 |
5 .测试报告
不合格
|
合格
|
优秀
|
1, 没有按时完成;
2, 没有按照实际情况编写; 3, 内容描述不清晰 / 准确 |
1, 按时完成;
2, 基本按照实际情况编写; 3, 内容描述基本清晰 / 准确 |
1, 基于‘合格’之上;
2, 内容描述清晰 / 准确,有效协助开发分析所发现的问题 |