评审管理小结
从被评审的对象上来说，需求评审，设计评审，用例评审等等，都是测试团队应该参与评审的对象。进一步说，项目所有阶段的产出，与测试工作开展相关，并且测试团队具备评审能力的，都应该积极参加。测试管理人员应该将评审视作测试活动的重要组成部分。
在具体总结评审的标准流程之前，先来讨论一下评审可能会出现的问题。
很多项目也会组织评审工作，但是往往得不到非常直观的效果，究其原因问题可能会出现在以下方面：
- 问题1：没有足够的准备
临时召开的评审会议，与会者对于评审内容和对象没有充分的了解和准备。导致的结果是评审会议变成讨论会议，收效不佳甚至为零。
- 问题2：偏离评审目标
由于评审目不明确，可能达不到理想效果。比如，评审者可能对于文档格式等过于关注；又比如一个评审会议往往容易演变成技术讨论和决策会议，甚至是吐槽大会。
- 问题3：没有做好问题跟踪
评审发现了问题，却没有后续的过程去追踪和解决问题，导致评审失去意义。
- 问题4：评审没有被纳入计划
评审未被纳入计划中，导致的问题就是所有评审的展开都将需要占用额外的时间。这属于规划上的问题，一旦项目时间紧急的情况下，评审很有可能就要为其他的任务让位。
- 问题5：评审参与度不足
也是常见的现象，评审的参与人员特别是开发人员，常常会以消极的态度看待评审，参与程度不高。
计划
正式的评审需要一整套过程的支持，所以需要提前做好计划。计划中需要明确的内容包括：评审采用的流程、评审的目标、时间场地安排、参与人员、角色分配等，对于更为正式的评审，可能还需要定义入口和出口准则（即开始、结束条件）。
启动
完善的评审过程应该包括启动阶段，这个阶段的意义在于做好被测对象（比如需求文档）的分发到位，并明确评审的目标，可能情况下主持者还要解答与会人员的疑问。
个人评审
正式会议开始之前，需要留给与会人员时间，先行评审文档，为评审会议做准备，并且标注和归纳自己发现的可能缺陷、问题和建议；
评审会议
评审会议上由评审的组织者主持对所有被指出的问题、疑问进行讨论，讨论的重心应该落脚于问题的确定以及影响程度的判断，而非问题的解决方案。问题的解决应该是会后的工作。
会议应该目标于得出问题清单，以及问题的责任人、级别等。
返工阶段
在评审会议中，我们得出问题清单以及相关信息汇总，这远非评审的终结。既然知道了问题，那么接下来的工作一定是解决这些问题，这就是返工阶段的意义。责任人需要在预设的时间周期内，完成问题的解决、修复。
追踪阶段
最后我们需要跟踪问题的修复，并确定评审的工作已达结束标准。
如果对于被评对象具有比较多的疑虑，返工之后的二次甚至多次评审也是有可能的。