今天早上看了一个帖子，介绍说谷歌、英特尔、领英这几家公司已经放弃KPI，专项OKR。好奇之下看了一下OKR的解释。看完之后，倒也不能说没有收获，只是感觉想在现在自己的部门里推行还有挺多难度。想了解的朋友点击此处。
作为测试部的leader，有时候不得不对部门里做一些强制性的要求和检查，不管怎么说，我始终觉得，管理的理论是否先进并不重要，重要的是这个理论是否能解决实际问题，是否适用于自己的公司。
今天早上整理了一下对测试部的要求，欢迎大家来交流。
| 编号 | 类型 | 检查观点 | 备注 |
| 1 | 日常邮件 | 开始测试工作前需要将当前版本相关的测试用例OR测试点以邮件形式发送部门全员并抄送项目组，避免出现漏测现象 邮件名称：【测试范围】XXXX项目XXXX版本测试范围_YYYYMMDD |
补丁不需要；缺陷修复版本提交必测清单，检查是否改出新问题 |
| 2 | 版本测试完毕后当日需要将当前版本的测试结果以及测试报告以邮件的形式发送部门全员并抄送项目组 邮件名称：【测试结果】XXXX项目XXXX版本测试结果_YYYYMMDD |
X5的结束以测试报告的发出时间为准 | |
| 3 | 测试过程中每日需要发送项目日报 邮件名称：【XXXX项目】测试情况_YYYYMMDD |
||
| 4 | 青铜器缺陷 | 测试过程中发现的问题均要登记青铜器，避免出现口头提醒，后续无法跟踪的情况 | |
| 5 | 提交缺陷的数量，不同的项目阶段提交数量标准有不同，视具体情况而定。 | 能发现多少bug，是比较客观的体现工作有效性的衡量标准 | |
| 6 | 提交缺陷的质量，即提交缺陷的价值。一般来讲UI方面的价值较低，而业务方面的缺陷价值相对较高。 | 尽量能从用户业务层面上发现问题 | |
| 7 | 测试用例填写要符合部门要求(缺陷级别、复现步骤、日志、截图等)，让其他人员能够清晰无二意的理解，必要的资料要提供完整 | 减少沟通成本 | |
| 8 | 测试计划 | 该考虑的风险(新技术、工期、测试环境限制等)是否都考虑到了 | |
| 9 | 工作量评估是否准确 | 避免过于紧张和过于宽松，确保测试质量 | |
| 10 | 测试用例 | 每个系统都要有测试用例OR测试点，识别工作需要预留测试用例编写时间 | |
| 11 | 用例是否按时完成 | ||
| 12 | 考虑是否周到全面 | ||
| 13 | 是否有就更好的测试方法组织培训和分享 | ||
| 14 | 测试用例要符合部门对于测试用例的要求(格式、优先级识别等) | ||
| 15 | 测试报告 | 测试报告发布要及时，原则上版本测试完毕的当日以邮件形式发出，特殊情况需要提前沟通 | |
| 16 | 测试报告中信息要准确，不能出现前后数据明显对不起来等类似问题 | ||
| 17 | 对于失败、锁定的用例是否给予说明？ | ||
| 18 | 失败的用例有没有说明原因？ | ||
| 19 | 是否及时汇报严重问题和风险，同时面对面跟开发沟通确认？ | ||
| 20 | 测试报告是否能够真实反映项目的真实情况，不会对项目相关人员误导 | ||
| 21 | 工作任务&执行 | 每项工作任务的投入时间需要描述清楚，对于多任务填写到一个大任务的情况需要分别描述每项工作的投入时间 | 按实际投入投入时间填写 |
| 22 | 每项任务都必须将输出物上传VSS或SVN，并在青铜器提交任务时明确输出物路径 | ||
| 23 | 工作时间投入同输出物产出要成正比，明显存在偏差的需要严肃处理 | ||
| 24 | 能否站在用户和业务的角度上测试，能否考虑到用例之外可能存在的问题 | ||
| 25 | 测试任务能否及时甚至提前完成 | ||
| 26 | 能否主动推进问题解决 | ||
| 27 | 是否能对好的工作方法进行提炼并组织培训进行分析 | ||
| 28 | 遗漏了什么类型的bug | ||
| 29 | 青铜器 | 版本测试完毕后需要在完成当天更新青铜器版本流程 | |
| 30 | 缺陷回归完毕后需要在当天更新缺陷的状态，以便研发能够顺畅开展后续工作 | ||
| 31 | 青铜器工作日志需要在每天下班前填写完毕 | ||
| 32 | 其他 | 在信守自己的诺言方面做得如何？ | |
| 33 | 是否在学习新技能？在把自己的技能传授给其他测试员方面做得如何？ | ||
| 34 | 有站在公司的立场上处理过什么问题？ |
(0 0)
+------oOO---(_)------------+
| |
| 『欢迎关注』 |
| 张老师的小黑屋 |
+--------------------oOO-----+
|__|__|
|| ||
ooO Ooo