测试管理 - 基于产品风险的测试策略

对于测试工程师而言，随着在这个行业的深耕，逐渐会接触到一些项目层次的理念和方法论。

风险分析以及风险管理就是其中重要的一项。

风险管理与质量控制实际存在着很是大的关联关系，也是管理测试的有效理念。

 

 

 

 

1. 什么是风险

在项目管理的领域内，风险被定义为：某一事件发生给项目目标带来不利影响的可能性。

 

在开发新的软件系统过程当中，因为存在许多不肯定因素，软件开发失败的风险是客观存在的。所以，风险分析对于软件项目管理是决定性的。风险管理是项目管理团队的重要职责，也是促使项目成功的有效办法，测试管理人员以及整个测试团队在这个过程中要起到很是重要的做用。

风险分析实际上就是贯穿在软件工程过程当中的一系列风险管理步骤，其中包括：风险识别、风险评估、风险策略、风险解决和风险监督等。

对大多数软件研发组织和项目而言，当谈及风险的时候，通常分为两个方面：

• 项目风险（过程风险）
• 产品风险（质量风险）

咱们首先要将这两个概念区分开来，由于测试团队在这两项风险管理过程当中的任务多是大相径庭的。

 

1.1 项目风险

项目风险或者叫“过程风险”是围绕项目按目标交付的能力的一系列风险，好比来自组织方面，人员管理方面，流程方面和其余方面的风险。

 

 

咱们只对测试工程中常见的风险作一个大体罗列，如：

• 技能、培训和人员不足；
• 项目团队成员出现的我的问题，人员流失；
• 组织内部协做不调，缺少有效的沟通渠道；
• 管理流程缺少组织，测试工做的支撑和依赖没法获得知足；
• 项目成员尤为是管理人员可能对测试团队抱有错误的态度和认知；
• 有效的测试方法（好比静态测试）不受重视；
• 技术支持的缺少致使的测试技术问题；
• 测试时间受到压缩；
• 交付的代码质量低下，加剧测试以及返工任务量；
• 产品的缺失配置管理，变动流程等控制手段；
• 离岸团队的合做效率问题；
• 第三方支持的问题；

以上都是可能影响到测试任务完成的常见项目风险，管理人员须要在计划阶段对风险进行预估，并给出规避方案和应急措施。

 

1.2. 产品风险

产品风险又称为“质量风险”，用通俗的话讲即为：“产品交付以后可能带有的质量问题”。

为何咱们研发的软件产品会有风险存在呢？问这个问题实际就等同于问“为何软件产品可能会有缺陷呢”？

其实其本质在于“人都是会犯错误的”这样一个论断的成立。

基于这个论断咱们又能够推论出：“由于人都会犯错误，因此人开发出来的软件也就可能带有错误”。

这些在研发过程当中咱们犯的错误，遗留在产品中，就是缺陷；缺陷存在的可能性，就是产品风险。

产品风险产生的缘由，可能有如下这些：

1. 产品大小/代码量：工做量越大，那么咱们就越有可能犯错。
2. 技术因素：不曾使用过的新技术都存在风险。包括未使用过的新型硬件、支持软件，缺少标准与规范的非传统的开发方法等。技术过期也是风险。
3. 开发环境：适用的开发工具不足、不可靠、使用不方便等因素，都会下降开发效率。
4. 组织规模和人员经验：好比人手不足，人员经验不丰富，都有可能带来产品风险。
5. 客户因素：表如今客户需求常常矛盾，不了解客户的特殊须要，客户不了解项目中采用的新技术，且双方又难于沟通等。

在软件研发领域，经过测试过程发现而且解决问题，实际就是产品风险的最重要和直接的规避手段。

换言之，软件测试就是产品风险管理的重要手段，也即产品风险控制的有效办法，甚至有些组织会将软件测试从组织架构上归入风险管控部门。

常见的软件产品风险有以下类型：

• 软件的故障频发；
• 软件/硬件对我的或公司形成损害；
• 软件特性低劣，好比性能低下；
• 数据完整性不足；
• 既定的功能未被彻底知足；

等等。能够看到，以上的软件产品风险，咱们软件测试的活动和任务都有可能对他们进行评估，而且经过信息收集和事件报告等手段实现规避和控制的目的。

 

2. 项目风险管理

风险管理通常经过下面四个阶段来完成：

1. 风险识别
2. 风险评估
3. 风险缓解
4. 风险监控

 在进行风险管理的过程当中，要把握好四个原则：

• 可避免的风险，采起好的过程管理和流程控制来应对；
• 不可避免的风险，采起下降和转移的措施；
• 作好风险管理计划；
• 作好应急方案；

 

咱们列举一下测试过程当中可能存在的风险和对应的可行举措：

对于测试过程风险：

• 需求的计划外变动
  • 作好变动控制和配置管理
  • 为可能的变动预留时间和人员的调整空间
• 测试用例执行率不足
  • 平常跟踪全部工做过程，及时发现阻碍测试执行的因素并协调解决
• 测试分析产生误差
  • 更完善的测试分析流程，对于经验不足的人员安排指导
  • 用评审的手段予以检查
• 测试用例设计不足
  • 更完善的测试分析流程
  • 充足的人员技能培训和指导
  • 用例评审的把关
测试与生产环境差别
• 尽可能缩小测试环境与生产环境的差别，好比使用更大的数据量
• 更强的客户响应以肯定用户生产环境的特性
• 偶现类问题
  • 倡议充分的问题记录和分析流程
• 代码质量太低
  • 更好的单元测试实行
  • 倡议和创建规范的提测控制流程
• 回归测试覆盖率不足
  • 适合的回归测试策略
  • 自动化的回归测试覆盖

 

对于人员风险：

• 人员流失
  • 积极响应人员诉求
  • 创造更积极的工做流程及环境
  • 作好人员技能储备
• 人员不可用状态（休假等）
  • 创建良好的文档归档流程
  • 创建完善的工做后备机制（不可以让某项工做只有某一我的能完成）
  • 协调完备的人员抽调机制
• 新人工做准备
  • 创建良好的人员培训机制
  • 创建帮助新人融入的导师机制
• 外包人员管理
  • 控制项目团队中外包或兼职人员的比例
  • 与外包人员保持足够的沟通和把控
  • 与外包公司保持足够的管理联系

 

能够看到这部分项目风险预估和应对的内容，更多的出如今测试计划以及一些项目筹划会议上，应划归为项目管理范畴。

 

3. 基于风险的测试

上文提到，项目风险须要经过管理手段和策略来缓解规避。

那么产品风险呢？长话短说：测试（质量控制）就是下降产品风险的行之有效的手段。

 

 

正由于如此，因此以风险为基准来制定的策略是测试领域内很是重要也很是普及的一种方法。

这就是所谓的基于风险的测试（Risk Based Test - RBT）。

常见的测试策略可能有：

• 分析型策略
• 基于模型的策略（如：基于运行概况分析的测试） ·
• 符合过程或标准的策略（如符合OWASP标准的web安全测试）
• 应对型策略（如：探索性测试）
• 咨询式策略（如：外部机构测试）
• 面向回归测试策略（如：自动化回归测试）

而基于风险的测试就是典型的分析性策略。

正如咱们前文中提到的项目风险和产品风险的区别，基于风险的测试是基于“产品”风险而非项目风险。经过对于产品不一样区域和特性可能遗留缺陷，以及其影响程度的分析，肯定测试的资源分配等问题。

基于风险的测试策略之因此有很大的应用价值，是基于如下几个基本论断：

1. 事有轻重缓急，对于测试工程而言，并不是全部被测对象和模块都具备同等的重要程度。
2. 测试不可穷尽，测试成本和错误成本处在天平两端，用更少的资源和成本覆盖更多更重要的测试目标是测试管理的重要诉求。
3. 缺陷具备集群性，经验而论，对于缺陷集中的模块投入更多的测试关注度和资源能够最有效的发现最多的缺陷，从而带来质量的快速提高。

 

 

下面咱们经过一个简化版的RBT实例来论述其组织实施过程。

某税务处理系统

• 该项目为一个COTS产品的定制性二次开发项目
• 项目周期计划为4个月
• 采用持续集成，高速迭代的研发方式

①风险识别：识别出软件研发过程当中，可能产生缺陷的区域，包括功能模块和专项问题，罗列以下：

这个风险识别的过程，能够依靠专家的分析，好比测试经理和开发组长、项目经理等的讨论，可是更多的状况下应该依靠集体智慧，条件容许的话项目全部利益相关方，都应该参与到风险分析的过程当中来。在风险识别这个动做上，头脑风暴是一种可行的方法（即与会各方各抒己见，提出本身认为产品可能有的风险项）。

除了头脑风暴法之外，更为严格的风险研讨会议，经验总结会议，第三方独立评估，问卷调查法都是可使用的风险识别方法。不一样的人员处在不一样角度和专业背景下，对于风险的识别和分析等能够提供更全面专业的思路。

 

②风险评估：在风险评估过程当中，咱们要对上个阶段列出的风险项目作出评估，得出风险高低大小的一个排序。

风险评估中须要考虑的两个维度：风险发生的可能性大小，以及风险若是发生，带来的影响范围和严重程度。两个维度结合起来，才最终定义一个风险项目的级别高低。

所以，首先须要肯定咱们对于这两个维度以及风险级别之间的判别关系，采用风险定义矩阵是一个比较好的作法，好比采用以下风险分析矩阵：

 

将识别阶段得出的风险项目列表进行两个维度的风险判断，得出以下结果：每个风险项都从两个维度给他’高、中、低‘的判断，得出下表：

 

 

按照风险分析矩阵，进一步整理：

 

  

到此为止咱们已经获得了风险评估结果列表，可使用风险追踪表格管理起来。

在这个评估过程当中，只是使用简单的高中低三个级别的划分对于风险进行评估。若是须要更为精细的评估，也能够采用更为细致的评分方式，而且对于风险的发生几率和影响度能够分开进行更为严格的评估，好比使用下表进行的发生几率分析：

 

 

 同理对于另外的影响范围和严重程度，也能够作出相似的分析评估。

最后使用（可能性X影响）的公式得出风险项目的最终级别。

 

③风险缓解

基于产品风险分析，测试管理人员能够在测试活动的安排上，实施缓解措施：

肯定测试优先级

根据测试风险的分析和评估获得的风险分布，肯定测试的优先级。如上例中，将风险级别最高的三个项目定位最高优先级，优先进行测试分析、设计和执行。其余项以此类推。

肯定测试完备性

前面提到的一个假设条件：并非全部的测试对项目而言是同等重要的。一样的道理，并不须要对测试对象的不一样内容进行同等重要的测试，最重要或者风险最大的模块或者对象须要测试得更加完全，更加完备。而对于风险比较小、优先级低的模块或对象，能够简单测试。对于优先级最低的对象，在时间和成本等不容许的时候，甚至不进行测试。

为达到更高的完备度，能够采用更为严格的测试分析、设计，更为全面的执行和测试覆盖。

测试资源优化分配

根据测试风险的分析和测试优先级的评估，将经验丰富和技术能力丰富的测试人员（无论是设计人员、实现人员，仍是执行人员）放在最重要的模块或测试对象中，能够达到以下效果：

• 设计更加完善、完备和准确的测试用例。
• 实现高质量的测试用例脚本和代码。
• 更加高效地发现测试对象中的缺陷。

这种基于风险的测试策略能够很是有效的帮助测试团队快速实现重要模块的测试覆盖，而且能够有效的快速提高产品质量，进而带来利益相关方的信心提高。同时，对于测试监控而言也是很是有帮助的。

 

④风险追踪

风险分析不是一个一次性的工做，须要持续追踪。经过在项目实际研发过程当中获得的信息和反馈，对风险等级进行调整，好比调高和调低风险等级。

一个实际的例子是：当项目开始时，将某一个风险项目定为了高级，所以这个风险项颇有可能引发了团队的重视。而正由于团队对这个风险项目很重视，以致于在后续工做开展过程当中，团队投入了更多的资源和力量，致使最终测试阶段可能反而在这个模块里面没有发现太多问题，也即他真正展现出来的风险等级并无预计的那么高。当发现这样的现象时，应该对风险跟踪表作出及时更新。

风险级别的更新能够是即时的，即发现现象则对应更改；也能够是阶段性的，好比每周一次，对于风险项目进行更新和调整。

风险级别一旦发生调整，测试活动的安排也应随之相应调整。

 

4. 总结

风险的控制，在企业生产和管理中是被广为接受和采纳的理念。

对于软件产业而言，产品质量风险的缓解很大程度依赖于测试工做所提供的质量控制（QC）。

也许并非全部测试人员都会采用如本文所述的精益化的风险管理过程，但无论是对于测试管理人员仍是测试技术人员而言，风险的观念都是不可或缺的。

不论采用怎样的测试过程，都应采用风险管控理解来编排工做，抓住重心，这样才能将有限的（有时很是有限！）测试时间合理投入到无限的任务中去。