【落叶113】“老兵聊测试”之我眼里的风险管理

文/秋之川

【目录】

这是《落叶》文集里第 113 片落叶，希望你能喜欢，不为别的，只为这份坚持。

风险管理是指如何在项目或者企业，一个肯定有风险的环境里把风险可能造成的不良影响减至最低的管理过程。风险管理的内容包括风险管理计划、风险识别、定性风险分析、定量风险分析、风险应对计划和风险监督与控制。

在执行过程中，项目风险管理可以简化为风险识别、风险度量、制定应对措施和风险监控四个步过程。

项目的风险管理是一个动态的工作过程。

项目风险识别是项目风险管理的重要环节。

在任何环境下做项目，风险都是无处不在的，也是最防不胜防的。项目风险其实就是一种不确定的事件或条件，假如发生，就会对项目造成积极或消极的影响，如范围、进度、成本和质量。

所以我们在做测试计划时，最重要的一项工作就是识别风险和制定风险应对方案。

上面我们了解了风险和风险管理的概念，风险管理就是在识别出项目可能有的风险之后，事先就可以做的或者是可以计划的一系列应对手段，最终目标是降低风险发生的概率或者是当风险发生时，如何能快速地、有效地去应对和解决风险所带来的后果。

主要有下面几个步骤：

1、描述清楚风险是什么，会带来什么样的严重后果，包括发生概率有多大；

2、分析风险产生的可能原因有哪些，可能发生在某个阶段或时间点；

3、针对每个原因再制定应对方案；

4、每个风险应对方案要有明确的责任人和时间计划节点；

在实际项目当中，常常会有人把风险产生的原因当做风险本身，问题虽然不大，但会导致计划里的风险计划清单可能会比较长，给人一种，这个项目的风险也太多了吧，还能正常完成吗的错觉。所以，今天就以软件测试项目中的常见风险为例，来做个风险管理计划。

【风险】：

测试执行时间被压缩，产品还未经过充分测试就发布上线，导致上线后用户投诉增多（70%）

【原因】：

1、产品需求出来的晚，而且也不完善清晰，多次反复评审的时间挤占了研发时间；

2、开发自测不充分，导致提测的版本质量不高，影响正常测试计划进度；

3、Bug 修复速度慢，阻碍了完整的新功能测试和最后的回归测试；

4、中后期需求频繁变更，或者是新增需求，导致测试资源被分散；

【应对方案】：

1、优化测试用例的设计，减少冗余的和无效的测试用例，同时提高自动化脚本的覆盖率，节省相应的人力用于新功能的验证测试；

2、制定测试包的可接收标准，编写 ATC （Acceptant Test Case），没达到可提测标准的一律退回，采取这种倒逼的方式，让开发提高自测质量；

3、和开发负责人明确 Bug Fix 的要求，每天几点之前要日清当天的 New Bug，同时，测试任务包尽可能拆解的小一些，独立一些，在某些模块出现阻碍性 bug 时，可以略过先去测试别的模块；

4、在做测试任务量评估时，预留10%~15%的 Buffer，用于应对需求变更和临时新增需求；

在实际的项目中，风险管理其实也是需要渐进递推的，在项目计划阶段，对于很多风险其实只是预估和猜测，它们可能发生，同理，也可能不会发生。

因为当时所处的时间位置，离项目结束还很远，有效的项目信息也比较少，很难看清风险的虚实。

只有当项目开始进行了，随着时间和进度的推移，离风险发生的时间位置越来越近，同时，项目信息也越来越丰富了，才能更加清楚地看到相应风险是否会如期发生，到那时候，当初计划好的应对方案，大多数都需要做一些适时地优化和调整。

所以，我认为风险是随着项目的推进在不断变化的，我们需要及时的识别和适时地出手应对，这也是风险管理的难点所在，当然，也是乐趣所在。

作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵

【目录】