这是《落叶》文集里第 *328 *片落叶,希望你能喜欢,不为别的,只为这份坚持。
第十三章 管理测试项目中的风险时应该关注些什么?
结合着老大给我的实例,我也自己参看了一些理论书籍,对于测试项目的风险,有几点是我应该重点关注的:
- 影响结果
(1)指的就是这类风险最终会导致的结果是什么,项目延期?发布后缺陷率上升?还是项目成本的增加?
(2)只有明确知道了最终的影响结果,我们才可以判断该风险的严重性是高还是低;
(3)只有判断出风险的严重性,我们才能决定是否有制定应对方案的必要; - 应对策略
(1)在实际的项目中,多数风险可能会发生,也可能不会发生,存在一定的概率,所以我们需要根据历史项目经验和相关的项目数据,来判断该风险发生的可能性;
(2)当项目开始了,随着时间和进度的推移,离风险可能发生的时间点越来越近,项目信息也越来越充分,那时候会更加容易地判断风险发生的可能性;
(3)降低风险所产生的影响结果是风险应对的一种手段,这个是我们最常用的,也是最容易采取的一种策略,比如说通过增加人力,优化流程来,减少需求变更等手段来将降低项目延期风险的影响;
(4)转移风险也是风险应对的一种手段,就是将可能有严重影响的风险转化为影响较小的风险,从概念上来看,觉得有些难搞,但实际上我们在项目中经常采用这种策略,我举个例子就清楚了:比如在项目的中后期,临近上线了,发现一个低概率碰到的程序 Crash Bug,要不要修复呢?
(1)如果要修复这个 bug,需要动到功能模块的底层库,测试需要做一轮 Full Regression Testing;
(2)但因为临近发布时间了,所以没有足够的时间去做,只能针对问题发生的周边范围做一轮简单地回归;
(3)这里的风险就是可能会导致较为严重的 Regression Bug 被漏到线上,这就是很严重的风险。
(4)我们一般碰到这种问题,都会怎么应对呢?肯定是将这个 Bug 延期到下个版本修复:- 首先,下个版本会有足够的时间做一轮充分的回归测试;
- 其次,本身那个 Crash Bug,用户碰到的概率就很低,这个风险就较低了;
- 应对方案
(1)应对方案的制定,我认为应该是随着项目进度的推进而从粗到细的,因为在项目刚开始时,有效的项目信息比较少,对于风险发生的可能性判断准确性比较低;
(2)项目开始时根据风险发生的可能性制定粗细不一的应对方案,等到风险清晰可见时再做一些优化和适时的调整,性价比会更高些;
最后,就我经历过的项目,我认为我们需要很清楚的认识到:绝大多数风险都是不可消除或者说避免的,如果说某个风险我们提前就知道怎么能不让它发生,那它就不应该算作风险。
风险最大的特点应该就是它的“不确定性”,而且,正因为风险的不确定性,我们才需要及时的识别并出手应对,这既是风险管理的难点所在,但也是其乐趣所在。
《告诉你如何从执行测试到管理测试》带你迈出第(13)步!,点击这里可查看完整地图
作者简介:14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵