测试管理之项目软件测试风险管理实践

发表于:2021-9-06 09:43  作者:梧桐苑落   来源:51Testing软件测试网原创

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试管理 测试管理

  在软件测试活动中,作为一名测试人员有没有遇到过这样的场景,在测试一个特性或者制定一份测试方案时,往往会想着进行简单测试、做简单设计,认为
  1、这个场景出现的概率太低,几乎不可能会存在,不测了
  2、实际应用时不可能会有这么大的用户量,不用考虑
  3、在这个时间段应该不可能会有这么大的业务量
  4、同一时刻不可能会存在多种业务并发上来
  但版本发布上线后,实际应用时之前认为的那些小概率事项,结果确往往就是会出现,这是为什么呢?管理学中有一个定律——墨菲定律;这个定律指出,当事情有变坏的可能,不管可能性有多小,他总是会发生;
  在具体的研发测试中,当测试过程、测试交付存在潜在风险导致出现不好的结果时,我们需要如何做好全方位的准备?积极的应对,避免不好事情造成的影响或把影响降到最低;结合当前项目运作,分享下当前项目过程中对于测试风险控制的实践过程。

  一、认识风险
  在项目活动中风险是指项目活动过程中的一种不确定的事件或条件,一旦发生会对具体的项目的单个或者多个目标产生影响,例如:
  ·研发过程中,特性需求临时变更,代码修改,但测试时间不足,存在质量风险
  ·版本交付,存在外部依赖不满足,交付受阻;
  ·版本测试,测试工作量估算不合理,测试不充分
  这些交付过程中存在的动态的、静态的、已知的、未知的不确定性因素影响测试交付目标,无法满足外部市场需要;那如何做呢?

  二、风险管理
  在项目的测试活动过程中,我们通过一系列风险控制活动对不确定因素进行及时识别、有效评估、积极应对,以保证项目测试活动的正常进行,从而达到价值交付;

  1.风险识别:
  在风险识别阶段通过树立团队整体的风险意识,大家一起讨论制定风险识别维度、在对应的研发阶段、利用一定的工具方法进行风险数据收集,从而进行有效识别。

  1)风险识别维度
  根据项目的实际运作团队讨论,通过收集如下四个维度的信息作为风险识别的输入,来进行识别
  项目:项目的维度主要考虑:
  ·项目规划需求的计划:在项目迭代开始初期,规划的需求内容、提交的计划点;如果在过程中发生需求加塞、提交计划变更和一开始的计划出现偏差,则作为风险进行及时上报;
  ·相关的制约因素:是否存在对外部依赖,比如对外围的软硬件版本存在依赖,需要提供后,集成完成才能满足交付条件;
  ·里程碑时间点:时间点要求也是一个识别依据,临近里程碑时间点,现状和目标存在较大偏差;
  ·工作量的估算;工作量估算的合理性,有些是项目强行压下的,存在较大的工作量偏差;
  ·以及隐形因素项目内各团队之间的合作协作关系
  资源:资源的维度主要考虑人力资源是否充分,设备环境资源是否能满足相应的测试活动;比如组网场景、容量上对资源的要求,是否具备;
  技术:技术的维度主要考虑当前是否存在新领域不熟悉、所需的技能存在盲区。
  质量:质量维度主要是要了解确认对任务质量的要求,是仅满足预研穿刺基本测试,还是需要按交付标准的DOD严格执行,以达到交付要求;

  2)风险识别阶段
  风险识别活动贯穿在整个测试活动的始终,从测试SE参与需求分析开始、编写测试策略、跟踪特性实现过程、交付系统测试以及其他(维护)各阶段都需要识别;

  3)风险识别方法
  ·专家判断:了解项目和业务各领域的人员,考虑单个风险的方方面面,以及整体项目风险的各来源;
  ·头脑风暴:参考一定的风险识别维度,进行相关的脑暴;
  ·访谈:对领域专家、资深参与者访谈;
  ·会议讨论:团队成员对当前所承接的任务,观察了解到的信息进行专门的会议讨论,审查识别的风险;
  ·风险检查单:各阶段的风险点,用作提醒(坚持单及时审查,定期更新调整)

  风险识别经验小结:
  1、团队树立风险意识,鼓励所有人相关人员参与风险识别
  2、除了显性可见风险,同时也要注意隐性的团队协作,氛围的风险

  2.风险评估
  通过有效描述风险,明确风险类别后合理定义风险级别来评估风险,以确认风险影响以及为后续的风险应对措施提供依据;

  1)风险描述:
  风险包含起因、时间、概率及影响四要素,在了解风险4要素后,使用结构化SQCA描述方法,把风险本身与风险愿意及风险影响区分开来,描述清楚;
  S(Situation):背景起因
  C(Complication):事件冲突
  Q(Question):问题影响
  A(Answer);答案
  描述结构化方式:在某个背景(起因)之下,遇到了复杂(事件)情况,产生了什么样的(问题)影响,然后我们如何去解决它(答案)
  其中风险描述中风险影响和解决方案是关键,建议描述要领:
  ·Q(问题影响):描述清楚波及的范围、问题的重要、紧迫程度
  ·A(解决方案):遵循3W原则,解决方案具体内容,包含所需要的资源等(What)、具体的责任主体(Who),由谁负责解决、期望解决的具体时间点(When)
  ·风险描述案例:
  ·技术风险描述举例:
  随着公司业务的快速发展(S),我们的IT系统无法满足现状产品的需求(C),这将导致我们无法满足我们的客户(Q),当务之急的应对措施是需要***立刻安排升级IT系统(A)
  ·质量风险描述举例:
  临近迭代交付(S),测试自动化无法稳定运行(C),导致守护不完善,存在质量风险影响发布(Q),当务之急***尽快在迭代交付前完成自动化执行守护修复(A)

  2)风险分类
  在有效的描述清楚风险后,进行风险分类,明确风险类别;这个过程主要是便于把注意力和精力集中到风险最大的领域,或者针对一组相关的风险制定通用的风险应对措施,从而更有效的开展应对;
  ·按风险来源分:技术风险、管理风险、外部风险、内部风险等
  ·或者按受影响的项目工作分:方案设计、编码实现、验收测试等
  目前我们项目运作过程中,风险分类主要还是以风险的来源来分,根据分类出的风险,发现外部依赖类风险占据比例较高,针对此类风险讨论通用的应对措施,比如通过一开始的协作规划项目计划来约束、过程中每日的日报、周报来跟踪外部依赖提供的进展等

  3)风险定级
  在描述清楚风险、做好分类后,团队根据具体的研发过程,对风险偏好和风险临界讨论制定风险影响和概率的定义,从而进行风险定级评估;
  比如通过风险出现的概率情况、对测试目标的影响程度来综合判断风险级别,具体定级示例:

  根据定级结果,高以上风险:立即行动 ;中风险:立即关注;低风险:定期关注

  3.风险应对:
  在风险评估定级完成后,进行对应的风险应对;在实际的项目运作过程中根据不同的场景,采用不同的应对措施;
  ·风险上报:当超出个人或团队处理的能力时,需要进行风险上报,一般风险级别为高以上类风险;比如涉及到外部依赖类风险,需要项目协调,否则版本无法正常集成制作;通过面对面、电话沟通、或者日报周报的方式上报反馈;
  ·风险规避:发生的概率较高,具有严重负面影响的高优先级风险;比如在临近版本发布时,某些特性由于测试不充分,波及不明确,合入后存在对现有商用版本存在未知隐患,通过裁剪、调整特性合入周期来规避版本发布质量风险;
  ·风险转移:应对风险,把责任外包给第三方;比如在研发过程中,对于新领域不熟悉,但第三方存在成熟的技术,可以通过购买服务、签约合同;和第三方达成合作,把风险转移第三方;
  ·风险减轻:降低风险出现的概率和影响;比如在临近版本发布时,合入了故障,但该故障的波及范围交广,测试又不充分;经过分析故障影响,回退合入故障,来规避影响;
  ·风险接受:对于低优先级的风险或者其他任何策略已无法加以应对;

  三、经验总结
  最后的话:
  1、测试过程中,当好测试“操盘手”,综合进行风险控制,做好全方位准备,积极应对,避免或降低坏事出现后造成的影响;
  2、加强团队风险意识,风险管理控制需要全员参与
  3、作为一名优秀的测试人员养成风险数据收集、整理、分析习惯;
  4、善于总结经验,练就一副识别风险的“火眼金睛”
  5、作为测试人员,要“未雨绸缪”,从源头控风险,不要当“救火队员”

  版权声明:本文出自51Testing会员投稿,51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

评 论

论坛新帖



建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海信义律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2021, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道