Review里的Checklist

刚做了几次质量阀评审，在整个评审过程中也是查了很多“Review”，所以对Review的兴趣还是意犹未尽。

今天写比较小的一个话题，相对正式的Review都是有一个“拐棍”的，就是Checklist。

Checklist的设置呢，会根据不同的对象有不同的专业性。不过，本文不谈专业，只谈通用的设置，这是因为面对纷繁复杂且不断更迭的技术，显然无法把握细节，更多的是基于产品/项目对方法 论的融会贯通。

以下是整理的一些条目：

1. ID设置是否正确？

2. 版本是否正确？

3. 存储位置是否正确？

4. 既定规则是否符合？

5. 更新的文件是否是按照计划任务定义的？

6. 模板是否是正确或最新？

7. 必填项目是否均已填入？

8. 是否文档化及存档？

9. 被评审项是否被验证、被基线化和正式释放？

10. 是否建立Link，如需求和测试用例？

11. 是否使用了正确版本的软件？

12. 计划的内容是否均完成？

13. 文档是否有专属ID？

14. 是否经过特定专家的Review？

15. 上一阶段/版本的开口项是否已在这一阶段/版本关闭？

16. 系统和软件的匹配关系是否经过检查？

17. 变更原因是否记录？

18. 某“易错项”设置是否正确？

19. 所有在A上的更新是否在与其相关的B上体现？

20. 单位设置正确吗？

21. 前后保持一致吗？

22. 被删除的部分真的不需要了吗？

23. 是否有详细、合理和可被理解的描述？

24. 它的前提条件是什么？满足了吗？

25. 这些条目是否是可理解的？

26. 是否得到特定部门/角色的认可？

27. 文件的结构是否合理？

28. 粒度是否足够？

29. 是否使用了一致的专业术语？

30. 是否没有定性的相对描述，如小的、大的？

31. 组件的划分是否合适(模块化、高内聚和低耦合……)？

32. 文档历史是否有日期、修改和作者？

33. HW通常也会对SW产生影响，这些依赖项是否被清楚地识别？

34. 是否清楚地描述了先决条件和准备工作？

35. 每个组件的输入和输出是否完整？

36. 是否所有的测试用例都至少有一个到相应需求的外链接？

37. 需求是否与我们的系统概念和设计规则一致？

38. 实施这些要求是否存在任何风险？

39. 替代需求能否缩短与现有解决方案之间的距离？

40. 是否每个测试步骤都有一个序列号来指示测试步骤的顺序，并为预期和获得的结果提供唯一的映射？

41. Excel筛选里是否有未设置内容？

42. 对于更改，将生成的输出与更改前生成的输出进行比较，更改是否合理？

……

列的条目多是针对基本的完整性和逻辑性检查，但对于一个优秀的质量，这些远远不够，深入业务运作、产品细节还是非常必要的，不能够把握评审对象的细节正确性和现实适用性，永远只是纸上谈兵。

另外，最后再解释下，中英混杂不是为了装X，只是大家的习惯表达。