质量风险分析过程
不管选择哪种技术，都可以遵循一个相似的质量风险分析过程。
1.识别质量风险分析小组；
2.选择一种技术；
3.识别质量风险，对风险进行优先排序。选择合适的风险缓解方式。（不仅包括测试的各个阶段，而且包括审查需求、设计和代码、编程技术等一系列检查范围等等）；
4.如果风险分析小组识别出需求、设计、代码或其他项目文档、模型或已交付产品的问题，会报告这些问题，寻求解决方法；
5.审核、修改和定稿质量风险分析文件；
6.检查质量风险分析文件纳入项目库的变更控制之下。
7.定期（比如，重要的项目里程碑，如需求、设计和实施阶段完成，测试准备及退出审查时）及出现新的信息（比如，测试周期完成）时，检查并更新风险分析，增加新的条目并重新估算新条目的风险等级。
作者更喜欢利用头脑风暴或类似有启发性的技术，把步骤3作为一个单独的单元进行。但是，在被风险分析控告的人和质量风险分析小组之间，他把这一步作为一系列会话，甚至是一对一的会话，执行了。
除了选择合适的技术，为了在质量风险分析过程中获得更多有用的东西，还有必要选择合适的参与者。需要一个在测试和质量方面代表所有利益相关者利益的跨职能的小组。如果不是代表所有各方的利益，那么就有可能遗漏一些关键的风险，也可能过高或过低的估计了一些风险的等级。
谁是关键的利益相关者？一般的规则是有两个群体。首先，理解顾客和/或用户需求和利益的那些人，或者与测试过程有直接关系的那些人。（必要时，顾客和用户也可能参与进来。）从商业方面考虑，他们能帮助评估出潜在问题的影响力。其次，洞察系统技术细节的那些人。从技术方面考虑，他们能帮助评估出潜在问题的可能性。
在过程中，除了有信息收集的性质，建立共识也是至关重要的。关注商业和关注技术的参与者都能、也应该协助进行风险优先级分类，并选择可以减轻风险的战略方案。
案例分析：质量风险分析过程
对互联网应用来说，作者把质量风险分析看作一系列的会话，并与组织中的关键管理者和技术领导进行讨论。他已经起草了销售需求和设计规范，以及一个可在各利益相关者之间共享的高水平系统的构思。这个风险分析讨论在作者和他的助手之间就测试工作已经达成了坚实的共识。
质量风险分析过程有两个需要注意的副作用。第一，它解释了系统的版本是不断演变的，不是一成不变的，尤其是在细节上。对什么有风险、什么质量优良达成一致意见，有助于促进理解共识对系统质量的意义。第二，风险分析（连同随后的测试设计工作）突出了需求和设计文档的许多问题。解决问题，防止缺陷进入测试过程。
拿文档安全应用来说，作者的客户没有书面的规范。拿互联网应用来说，建一个共享版的系统。幸运的是，作者能够利用一个下午的时间召集所有的利益相关者召开一个关于质量风险分析的会议。由此产生的文档可作为测试重点指南和测试设计过程的第一步。
除了创建有用的文档，还有两个需要注意的副作用。第一，开发小组决定采取措施积极主动地预防缺陷发生。令人鼓舞的是质量风险分析会议上，开发主管和技术领导采取诸如加强设计和代码审查的质量风险减缓措施。第二，风险分析文档成为实际需要的文件。由于质量风险分析侧重于不做什么，所以他们会否定地表达需求。
用质量风险的总体等级确定测试资源
质量风险分析应该识别风险本身及与其相当等级的风险。要确定风险的等级，其可能性和影响力是考虑的主要因素。作者喜欢把这两项分为五个等级：非常高、高、中、地、非常低。失效模式及效应分析考虑三个因素--发现问题的严重性、优先级和可能性--变化范围从1到10。
把这两个（或三个）因素转化为一个，聚合风险等级，人们可以运用质量风险分析小组的集体判断，一个公式或一个表格。在互联网应用案例的分析中，作者依靠集体判断来决定风险适当的总体等级。在文件安全案例分析中，他按照失效模式和效应分析标准从三个因素的等级级别中得到从1到1000风险优先级数，然后它被分解成代表不同总体风险的等级范围。要使用表，首先建立一个类似表3所示的查找表，然后在每个风险条目两个因素的基础上，用它来分配风险的总体等级。假设给定总体风险等级，然后人们就可以用它们来确定他或她想要进行测试的范围。例如，可能采用的规则列于表4中。
表3：集合两个风险因素的查找表
在表4中，注意不进行非常低和低风险范围的测试。对于中、高和非常高的风险，他或她承诺通过增加时间和工作量进行测试，以减少相关风险。那么每个级别合适的分界线在哪里呢？这是利益相关者的又一个问题。做那个界别的测试会使利益相关者感觉满意，每个风险得到充分的缓解。
这个问题的答案必须是切合实际的。在没有任何限制的情况下，人们可能喜欢对大多数而不是所有风险做大量测试。然而，如前所述，这是不可能的。所以，风险分析的每个参与者要问的是：“通过测试来减轻风险，我愿意消耗--在时间、项目预算、甚至是可能失去功能方面--的是什么？”
表4：映射相关质量风险的测试范围
