评审管理小结 - 附用例评审模板

本贴最后更新于 1534 天前,其中的信息可能已经东海扬尘

一、评审概述

通常意义上的测试过程,是一个执行被测软件的过程。但是随着软件测试行业的技术理念随着时代越来越成熟,不执行被测系统的测试,即“静态测试”开始受到更多的重视。

评审就是静态测试的一种重要开展形式,也是“测试尽早介入”原则的最佳实践方式之一。

在项目中常见可能采用的评审类型有:

从被评审的对象上来说,需求评审,设计评审,用例评审等等,都是测试团队应该参与评审的对象。进一步说,项目所有阶段的产出,与测试工作开展相关,并且测试团队具备评审能力的,都应该积极参加。测试管理人员应该将评审视作测试活动的重要组成部分。

评审是一种通过阅读,分析和讨论发现问题的活动。与动态测试即通常意义上所言的测试执行相比,评审可以帮助团队从更上游的阶段施加检测,从而高效的发现和解决问题。从这个角度来说,评审又是一种预防措施。比如,如果在需求评审阶段发现和解决了需求中的错误,那么则可以预防问题被带入到后续研发阶段,成本和投资回报上是一种非常有价值的活动。
评审的参与各方,可以划分为:

其中评审员负责做出具体评审,协调者则负责协调各方意见。

二、评审过程

在具体总结评审的标准流程之前,先来讨论一下评审可能会出现的问题。

很多项目也会组织评审工作,但是往往得不到非常直观的效果,究其原因问题可能会出现在以下方面:

临时召开的评审会议,与会者对于评审内容和对象没有充分的了解和准备。导致的结果是评审会议变成讨论会议,收效不佳甚至为零。

由于评审目不明确,可能达不到理想效果。比如,评审者可能对于文档格式等过于关注;又比如一个评审会议往往容易演变成技术讨论和决策会议,甚至是吐槽大会。

评审发现了问题,却没有后续的过程去追踪和解决问题,导致评审失去意义。

评审未被纳入计划中,导致的问题就是所有评审的展开都将需要占用额外的时间。这属于规划上的问题,一旦项目时间紧急的情况下,评审很有可能就要为其他的任务让位。

也是常见的现象,评审的参与人员特别是开发人员,常常会以消极的态度看待评审,参与程度不高。

要避免这些问题的发生,那么一个正式评审过程,需要明确定义以下阶段工作:

计划

正式的评审需要一整套过程的支持,所以需要提前做好计划。计划中需要明确的内容包括:评审采用的流程、评审的目标、时间场地安排、参与人员、角色分配等,对于更为正式的评审,可能还需要定义入口和出口准则(即开始、结束条件)。

启动

完善的评审过程应该包括启动阶段,这个阶段的意义在于做好被测对象(比如需求文档)的分发到位,并明确评审的目标,可能情况下主持者还要解答与会人员的疑问。

个人评审

正式会议开始之前,需要留给与会人员时间,先行评审文档,为评审会议做准备,并且标注和归纳自己发现的可能缺陷、问题和建议;

评审会议

评审会议上由评审的组织者主持对所有被指出的问题、疑问进行讨论,讨论的重心应该落脚于问题的确定以及影响程度的判断,而非问题的解决方案。问题的解决应该是会后的工作。

会议应该目标于得出问题清单,以及问题的责任人、级别等。

返工阶段

在评审会议中,我们得出问题清单以及相关信息汇总,这远非评审的终结。既然知道了问题,那么接下来的工作一定是解决这些问题,这就是返工阶段的意义。责任人需要在预设的时间周期内,完成问题的解决、修复。

追踪阶段

最后我们需要跟踪问题的修复,并确定评审的工作已达结束标准。

如果对于被评对象具有比较多的疑虑,返工之后的二次甚至多次评审也是有可能的。

最后附上用例评审模板一份,以供参考:
链接:https://pan.baidu.com/s/1gcDSli4thx9cwLbsijKqHw
提取码:2ri2

回帖
请输入回帖内容 ...