测试管理之项目软件测试风险管理实践-IT知识库

测试管理之项目软件测试风险管理实践-IT知识库

咨询热线

0731-82115773

精选文章 > IT知识库 > 测试管理之项目软件测试风险管理实践

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

时间:2021-09-03  发布:新梦想IT职业教育  来源:新梦想培训

软件测试活动中,作为一名测试人员有没有遇到过这样的场景,在测试一个特性或者制定一份测试方案时,往往会想着进行简单测试、做简单设计,认为:

1、这个场景出现的概率太低,几乎不可能会存在,不测了;

2、实际应用时不可能会有这么大的用户量,不用考虑;

3、在这个时间段应该不可能会有这么大的业务量;

4、同一时刻不可能会存在多种业务并发上来;

但版本发布上线后,实际应用时之前认为的那些小概率事项,结果往往就是会出现,这是为什么呢?管理学中有一个定律墨菲定律。

这个定律指出,当事情有变坏的可能,不管可能性有多小,但总是会发生。

在具体的研发测试中,当测试过程、测试交付存在潜在风险导致出现不好的结果时,我们需要如何做好全方位的准备?

积极的应对,避免不好事情造成的影响或把影响降到最低,结合当前项目运作,分享下当前项目过程中对于测试风险控制的实践过程。


01 认识风险

在项目活动中风险是指项目活动过程中的一种不确定的事件或条件,一旦发生会对具体的项目的单个或者多个目标产生影响,例如:

●研发过程中,特性需求临时变更,代码修改,但测试时间不足,存在质量风险

●版本交付,存在外部依赖不满足,交付受阻

●版本测试,测试工作量估算不合理,测试不充分

这些交付过程中存在的动态的、静态的、已知的、未知的不确定性因素影响测试交付目标,无法满足外部市场需要,那如何做呢?



02 险管理

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


#风险识别

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

1)风险识别维度

根据项目的实际运作团队讨论,通过收集如下四个维度的信息作为风险识别的输入,来进行识别。

项目,项目的维度主要考虑以下几点。

项目规划需求的计划:在项目迭代开始初期,规划的需求内容、提交的计划点。

如果在过程中发生需求加塞、提交计划变更和一开始的计划出现偏差,则作为风险进行及时上报。

相关的制约因素:是否存在对外部依赖,比如对外围的软硬件版本存在依赖,需要提供后,集成完成才能满足交付条件。

里程碑时间点:时间点要求也是一个识别依据,临近里程碑时间点,现状和目标存在较大偏差。

工作量的估算:工作量估算的合理性,有些是项目强行压下的,存在较大的工作量偏差。

以及隐形因素项目内各团队之间的合作协作关系。

资源,资源的维度主要考虑人力资源是否充分,设备环境资源是否能满足相应的测试活动。比如组网场景、容量上对资源的要求,是否具备。

技术,技术的维度主要考虑当前是否存在新领域不熟悉、所需的技能存在盲区。

质量,质量维度主要是要了解确认对任务质量的要求,是仅满足预研穿刺基本测试,还是需要按交付标准的DOD严格执行,以达到交付要求。

2)风险识别阶段

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

3)风险识别方法

专家判断:了解项目和业务各领域的人员,考虑单个风险的方方面面,以及整体项目风险的各来源。

头脑风暴:参考一定的风险识别维度,进行相关的脑暴。

访谈:对领域专家、资深参与者访谈。

会议讨论:团队成员对当前所承接的任务,观察了解到的信息进行专门的会议讨论,审查识别的风险。

风险检查单:各阶段的风险点,用作提醒(坚持及时审查,定期更新调整)。


#风险识别经验小结

1、团队树立风险意识,鼓励所有人相关人员参与风险识别;

2、除了显性可见风险,同时也要注意隐性的团队协作,氛围的风险。


#风险评估

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

1)风险描述

风险包含起因、时间、概率及影响四要素,在了解风险4要素后,使用结构化SQCA描述方法,把风险本身与风险愿意及风险影响区分开来,描述清楚。

●S(Situation):背景起因

●C( Complication) :事件冲突

●Q(Question):问题影响

●A(Answer):答案

描述结构化方式:在某个背景(起因)之下,遇到了复杂(事件)情况,产生了什么样的(问题)影响,然后我们如何去解决它(答案)。

其中风险描述中风险影响和解决方案是关键,建议描述要领:

●Q(问题影响) :描述清楚波及的范围、问题的重要、紧迫程度

●A(解决方案):遵循3W原则,解决方案具体内容,包含所需要的资源等(What)、具体的责任主体(Who)、由谁负责解决、期望解决的具体时间点(When )

技术风险描述举例:随着公司业务的快速发展(S),我们的IT系统无法满足现状产品的需求(C),这将导致我们无法满足我们的客户(Q),当务之急的应对措施是需要***立刻安排升级|T系统(A)。

质量风险描述举例:临近迭代交付(S),测试自动化无法稳定运行(C),导致守护不完善,存在质量风险影响发布(Q),当务之急***尽快在迭代交付前完成自动化执行守护修复(A)。

2)风险分类

在有效的描述清楚风险后,进行风险分类,明确风险类别。

这个过程主要是便于把注意力和精力集中到风险最大的领域,或者针对一组相关的风险制定通用的风险应对措施,从而更有效的开展应对。

●按风险来源分:技术风险、管理风险、外部风险、内部风险等。

●或者按受影响的项目工作分:方案设计、编码实现、验收测试等。

目前我们项目运作过程中,风险分类主要还是以风险的来源来分,根据分类出的风险,发现外部依赖类风险占据比例较高,针对此类风险讨论通用的应对措施,比如通过一开始的协作规划项目计划来约束、过程中每日的日报、周报来跟踪外部依赖提供的进展等。

3)风险定级

在描述清楚风险、做好分类后,团队根据具体的研发过程,对风险偏好和风险临界讨论制定风险影响和概率的定义,从而进行风险定级评估。

比如通过风险出现的概率情况、对测试目标的影响程度来综合判断风险级别:

新梦想IT职业教育


具体定级示例根据定级结果,高以上风险立即行动,中风险立即关注,低风险定期关注。


#风险应对

在风险评估定级完成后,进行对应的风险应对。

在实际的项目运作过程中根据不同的场景,采用不同的应对措施。

风险上报:当超出个人或团队处理的能力时,需要进行风险,上报。

一般风险级别为高以上类风险,比如涉及到外部依赖类风险,需要项目协调,否则版本无法正常集成制作。

通过面对面、电话沟通、或者日报周报的方式上报反馈。

风险规避:发生的概率较高,具有严重负面影响的高优先级风险。

比如在临近版本发布时,某些特性由于测试不充分,波及不明确,合入后存在对现有商用版本存在未知隐患,通过裁剪、调整特性合入周期来规避版本发布质量风险。

风险转移:应对风险,把责任外包给第三方。

比如在研发过程中,对于新领域不熟悉,但第三方存在成熟的技术,可以通过购买服务、签约合同,和第三方达成合作,把风险转移第三方。

风险减轻:降低风险出现的概率和影响。

比如在临近版本发布时,合入了故障,但该故障的波及范围较广,测试又不充分,经过分析故障影响,回退合入故障,来规避影响。

风险接受:对于低优先级的风险或者其他任何策略已无法加以应对。


03 经验总结

最后的话:

1、测试过程中,当好测试“操盘手”综合进行风险控制,做好全方位准备,积极应对,避免或降低坏事出现后造成的影响;

2、加强团队风险意识,风险管理控制需要全员参与;

3、作为一名优秀的测试人员养成风险数据收集、整理、分析习惯;

4、善于总结经验,练就一副识别风险的“火眼金睛”;

5、作为测试人员,要“未雨绸缪”,从源头控风险,不要当“ 救火队员”。


END

大咖面授 免费试听

测试管理之项目软件测试风险管理实践-IT知识库
技术支持 英铭科技