【敏捷测试】使基于风险的测试适应敏捷团队：在编码之前考虑测试

Evosoft Hungary Kft的产品专家CsabaSzökőcs表示，基于风险的测试可以提高交付故事的质量，并帮助系统测试人员成为Scrum团队的一员。在TestCon Moscow 2019，他解释了他们如何通过将其作为sprint计划和完成定义的一部分来适应经典的基于风险的测试以适应他们的敏捷实现。

Szökőcs介绍了他如何支持团队将测试活动从迭代结束到开始。几年前，当他们转向Scrum时，他们的开发团队并不真正知道如何提供经过全面测试的用户故事，并且不知道“潜在可交付”的含义。他们习惯于每年发布一次或两次，以及需要几个月的“系统测试”阶段（也就是“bug修复”）。现在有了Scrum，他们试图提供没有错误的故事，因此他们在新成立的Scrum团队中引入了更多的测试活动。

由于团队的测试经验较少，他们尝试使用已知的方法：在sprint开始时创建一个小设计，实现它，完成后测试它。 Szökőcs解释说，它是冲刺内部的迷你瀑布模型，与普通的瀑布模型具有相同的问题。

如果我们在测试期间发现了一个更大的问题，通常已经为时已经太晚了，无法正确修复它，我们不得不承担后果：接受错误并在以后修复它，减少故事的范围或引入快速解决方案。技术债务成本。这些都不好。

Szökőcs提到他已经在一个架构研讨会上学习了基于风险的测试，并且认为它可以对他们的Scrum团队有用。他们通过收集每个用户故事的风险进行尝试，然后再计划进入冲刺阶段。这有助于他们在故事实施之前考虑测试活动，并避免许多问题而不是对它们做出反应。他们很早就参与了系统测试员的同事，以便从他们的经验中受益。

Szökőcs说，基于风险的测试极大地改变了冲刺期间故事的处理方式，并提高了交付故事的质量。此外，对于系统测试人员来说，这也非常具有动力，因为他们能够影响故事的最终实现方式，他说。许多这些系统测试人员现在都是Scrum团队的一员。

“我们在一些Scrum团队中使用基于风险的测试，但不是在所有地方;一些团队已经尝试过，他们已经使用了很长时间，有些团队不是”，Szökőcs说。他提到他们已经将经典的基于风险的测试应用于他们的Scrum流程，以便更好地适应他们的敏捷实施。

Szökőcs说，通常基于风险的测试是在测试团队中完成的，以便在他们只有很短的测试时间时找到最有价值的测试。在Scrum团队中，他们正在针对几乎每个用户故事或史诗进行单独且独立的基于风险的测试;这是故事定义的一部分，故事的风险被收集和优先考虑。作为改进的一部分，他们正在收集风险，涉及特定主题的一些专家（系统测试人员，建筑师，产品所有者）。他们说，有时他们也会在系统中发现一些已经存在的错误，有时候他们也需要改变用户的故事，用一些特殊情况扩展验收标准，或者分割出非常棘手的方案。

收集风险后，两位同事根据风险的概率和损害优先排序，给每个人一个1到5之间的数字。乘以这些数字将提供风险暴露; Szökőcs说，所有高风险的风险都必须以某种方式处理。

他还提到，另外，经验丰富的测试人员会估算每种风险的测试有效性，并回答通过测试来处理这种风险有多容易？这也在1到5的范围内指定，其中1是不可能测试的，5是显而易见的。将这些数字乘以曝光将产生测试优先级编号（范围为1到125）。数字越大表示风险影响越大且易于测试，因此它具有最大的价值。 Szökőcs认为，较低的数字表示难以测试的低影响风险，因此最好忽略它，因为它没有实际价值。

优先排序有助于团队创建一个测试策略，其中包含针对具有最大影响的风险的有价值测试，而不是仅测试快乐的一天场景。 Szökőcs说，他们可以利用优先级来决定他们将测试特定风险的级别。

InfoQ在2017年莫斯科TestCon会谈后与CsabaSzökőcs进行了交谈。

InfoQ：您从Evosoft优先考虑风险的方式中学到了什么？

CsabaSzökőcs：首先，优先顺序是可选的。如果我们完全跳过它，那么收集风险仍然非常有价值。有些团队正在以这种方式工作，他们对此很满意。

其次，不要过度思考优先顺序。我们通常这样做：尝试找到数字最小的风险并给它一个1，然后是最高数字的风险并给它一个5.所有其他风险可以在很短的时间内迅速优先考虑。

第三，测试优先级确实有助于团队找到最有价值的故事测试，这可以提高所交付用户故事的整体质量。

InfoQ：你如何收集风险？

Szökőcs：我们通过回答“这个故事中可能出现什么问题？”的问题，在用户故事的背景下收集风险。

此外，我们试图想象新功能已经在运行并考虑不同的场景;如何使用或滥用。我们尝试将新功能与其他现有功能相结合 - 它能以某种方式出错吗？

还可以检查不同的非功能性要求，如性能，可用性和安全性;如果他们受到影响，他们会在这个故事中出错吗？如果系统负载很高，会出现什么问题？如果系统以某种方式变得不一致怎么办？

为了找到有价值的风险（不仅仅是不可能的情况），我们通常邀请该特定领域的专家：系统测试人员，或其他团队的架构师或产品所有者。这也是对他们的激励，因为他们也可以在团队实施任何事情之前对故事产生影响。

值得一提的是，我们并未收集项目风险，例如当团队中的某人生病或我们的预算不足时会发生什么。另外，我们不收集测试用例;我们可以只用一个测试用例来覆盖几个风险，或者我们只需要对一个风险进行多次测试。测试用例来自最重要的风险。

InfoQ：您进行基于风险的测试有哪些提示？

Szökőcs：试一试; 从简单开始，逐步改进。

一开始，如果您在每个用户故事中收集一些风险作为优化过程的一部分就足够了，并将它们记录在一个简单的列表中。 这将有助于团队感受故事的痛点并专注于他们。

之后，尝试邀请一些经验丰富的同事参加那次会议，收集风险。

如果您已经习惯了这一点，也可以尝试优先级。 看看这是否有助于团队定义更好或更有价值的测试用例。

不要将风险收集会议强制性或太长时间 - 团队可能已经超负荷召开会议; 他们不需要另一个。 与感兴趣的团队成员一起做，并让其他人完全跳过这个; 他们可以稍后查看结果。

最后：保持简单。 最有价值的是关于风险的讨论; 别忘了。