资讯专栏INFORMATION COLUMN

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

用户84 / 3549人阅读

摘要:在软件测试活动中,作为一名测试人员有没有遇到过这样的场景,在测试一个特性或者制定一份测试方案时,往往会想着进行简单测试做简单设计,认为这个场景出现的概率太低,几乎不可能会存在,不测了实际应用时不可能会有这么大的用户量,


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

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、作为测试人员,要“未雨绸缪”,从源头控风险,不要当“救火队员”

以上笔者的经历更像一张横向的知识网,创建了一个交流平台 914172719 ,群内有各种技术同行交流、学习资料、面试经验等。其中用到jenkins、docker、moutebank、python编程等,还需要花更多的精力去深入学习,当每项技能都能掌握到一定深度,才能称为一个完整的知识体系。

最后: 可以关注公众号:伤心的辣条 ! 进去有许多资料共享!资料都是面试时面试官必问的知识点,也包括了很多测试行业常见知识,其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一键三连哦!


好文推荐

转行面试,跳槽面试,软件测试人员都必须知道的这几种面试技巧!

面试经:一线城市搬砖!又面软件测试岗,5000就知足了…

面试官:工作三年,还来面初级测试?恐怕你的软件测试工程师的头衔要加双引号…

什么样的人适合从事软件测试工作?

那个准点下班的人,比我先升职了…

测试岗反复跳槽,跳着跳着就跳没了…

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/119350.html

相关文章

  • Flask Web 测试驱动开发最佳实践 开篇

    摘要:测试驱动开发简称,是一种软件开发过程中的应用方法,,由极限编程中倡导,以其倡导先写测试程序,然后编码实现其功能得名。测试驱动着整个开发过程首先,驱动代码的设计和功能的实现其后,驱动代码的再设计和重构。 showImg(https://segmentfault.com/img/remote/1460000017081716); 前言 一直都有听到 TDD 测试驱动开发的开发方式,之前看...

    fnngj 评论0 收藏0
  • Java程序员必读的书籍

    摘要:对于专业的开发者来说,单元测试是一项必备的技能,多数的程序员却不具备测试驱动开发的能力。对于工程来说,开源项目基本都严格遵守执行单元测试,而很多商业的工程则在单元测试方面有所缺失。一个拥有单元测试的项目会变得更加容易维护和更改。   作为一名合格的Java程序员,日常工作除了上班撸代码就是加班撸代码。撸码其实不难,无非询问Google,StackOverflow,解决方法和demo一箩...

    aisuhua 评论0 收藏0
  • Android 研发工程师图书一览(2016年版)

    摘要:番茄工作法简约而不简单,本书亦然。在番茄工作法一个个短短的分钟内,你收获的不仅仅是效率,还会有意想不到的成就感。 @author ASCE1885的 Github 简书 微博 CSDN 知乎本文由于潜在的商业目的,不开放全文转载许可,谢谢! showImg(/img/remote/1460000007319503?w=728&h=792); 广而告之时间:我的新书《Android 高...

    MadPecker 评论0 收藏0
  • Android 研发工程师图书一览(2016年版)

    摘要:番茄工作法简约而不简单,本书亦然。在番茄工作法一个个短短的分钟内,你收获的不仅仅是效率,还会有意想不到的成就感。 @author ASCE1885的 Github 简书 微博 CSDN 知乎本文由于潜在的商业目的,不开放全文转载许可,谢谢! showImg(https://segmentfault.com/img/remote/1460000007319503?w=728&h=792...

    NoraXie 评论0 收藏0
  • 在阿里,我们如何管理代码分支?

    摘要:摘要阿里有很多的研发团队,不同事业部使用的发布流程分支策略并非整齐划一,但总体上看是比较规整的。引言在阿里内部,流行着许多有意思的工程实践。比如分支管理这件事,其实属于工具和习惯各占一半,并且颇有阿里特色的成分,适合作为一个例子。 摘要: 阿里有很多的研发团队,不同事业部使用的发布流程、分支策略并非整齐划一,但总体上看是比较规整的。其中有一种主流的发布模式以及对应的分支使用方式,称为A...

    CocoaChina 评论0 收藏0

发表评论

0条评论

用户84

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<