敏捷团队的测试策略最佳实践

Scrum减去测试计划就等于POC的类固醇。

现在，大多数成功的项目都以概念验证（POC）开始，这是一个相对较小的想法评估，首先验证所选择的技术和功能包，评估其对业务用户的潜在影响，一旦被证明值得投资，就会指派一个全尺寸的项目团队来设计和交付全功能产品，并将其部署到生产环境中。

这对于Scrum团队来说是一个完美的案例。团队可以快速开发prototype，每个Sprint都添加大量新功能，而业务用户可以实时观察快速进展，以及如何在短短的10个Sprint内从头开始构建想法。这给人留下了深刻的印象（这本来就是POC的主要目标），但它也有一个重要的特点 – 最小或没有测试活动，甚至考虑测试过程都是一个笑话。

在Scrum团队内部，这并不是一项有趣的活动，人们大多会喜欢在不受任何减速环绕的情况下开发的想法。这基本上是任何测试活动隐含的。在我们最需要给最终用户留下深刻印象的时候，谁想要不必要的减速呢？

如果在POC期结束后，项目团队继续以相同的方式进行，那么发生的情况是我通常称之为“强化版POC”的状态 – 一个越来越大、功能越来越多的生产系统，但行为仍然像一个POC – 一个希望成为完整产品的产品，隐藏的缺陷和未经探索的边际案例只等待出现严重崩溃。

但在它转化之前，团队将更难跟上稳定版本的发布，因为修复不断出现的问题将变得更加复杂。

在我处理类似问题时，以下是一些被证明有效的技术，我认为它们可以被称为实施稳定测试流程的最佳实践，而不会过多地干扰开发进度 – 因为这就是我们所有人都希望成为Scrum团队的原因。

分担痛苦

在处理不必要的麻烦时，我们从哪里开始呢？就从分担痛苦开始吧：）。

我的意思是创建一个计划，需要开发人员在此处和那里增加少量的额外活动，但随着时间的推移，这将对共同目标产生巨大的贡献，逐步但持续。

#1.为每个创建的新代码编写单元测试代码

如果您设法说服您的Scrum团队在每个Sprint中添加单元测试的定义完成条款中，那么从长期来看，这将是一个巨大的成就。

原因非常明显：

它将迫使开发人员考虑代码的各种非标准路径。

• 这些单元测试可以插入自动化的链接管道中，并在每次部署到开发或测试环境时执行。此外，来自管道的度量标准可以被轻松导出，然后用于向业务用户演示与源代码直接相关的测试用例的百分比覆盖率。

最重要的是尽早开始。单元测试开始开发的时间越晚，对于开发人员在Sprint中添加它们而言，分心的程度就越大。

• 为已经存在的代码反向开发单元测试将需要很大的工作量。代码的某些部分可能是由另一个开发人员创建的，并且当前开发人员对它的每个代码部分应该如何工作的确切了解并不清楚。在某些情况下，为修改后的代码添加单元测试所花费的时间可能比为Sprint开发功能变更花费的时间还要长（这是在Sprint计划中肯定没有计算过的状态）。

#2. 在开发环境中执行单元测试的例程

甚至在创建合并新代码到主分支的拉取请求之前，对开发环境中的功能代码和unit test代码进行测试应成为标准操作。通过这样做，可以确保：

• 单元测试代码对于每个部分都有效（最终它只是另一段必须验证的代码）。这一步经常被完全跳过。有人认为，如果单元测试已经被插入到DevOps流程中，它最终会在某个地方被执行和测试。然而，这只是将问题推到了迭代活动的更高级别，团队通常在这些活动中时间更少，压力更大，需要完成每个已承诺的任务。
• 开发人员对新功能代码进行了基本功能测试。显然，不能期望这个测试完全验证了业务功能，但至少这个测试可以确认代码的行为符合开发人员的意图（暂时不考虑在开发过程中可能错误理解业务逻辑的问题）。

#3. 期望在代码合并到主分支后执行单元测试

在本地分支上拥有可运行的代码（除了分支所有者之外，没有其他人开发新功能）是一回事，但在拉取请求和合并到主分支后，让相同的代码能正常工作是完全不同的事情。

主分支包含了其他Scrum团队成员的更改，即使冲突已经解决，一切看起来都很好，合并和解决冲突后的代码基本上仍然是未经测试的代码，如果不先验证它仍然正常工作，进一步发送它是有风险的。

所以在这里被证明有效的方法就是简单地要求在由主分支代码版本构建的环境中，执行之前在开发环境上已经执行过的单元测试。

对开发人员来说，这可能是他们需要加入生活的额外一步，但不需要花费太多的努力，因为在这种情况下，不需要发明什么新东西 – 只需要重新执行已经完成一次的内容。

现在，在一个特定的情况下可以跳过这一步：

• DevOps流程中的自动化单元测试已经覆盖了在此之上执行的所有手动测试。

虽然实现这种状态绝对是可行的，但我从未在现实生活中经历过。对开发人员来说，创建如此详细的自动化单元测试可能太耗时。让团队投入这么多时间进行此活动可能会对产品负责人产生明确的影响，因为这将显式地影响在一个迭代中交付的故事数量。

然而，迭代内容的优先级永远不能成为不执行单元测试或将其最小化的借口。通过这样做，团队将再次使得代码缺乏充分的单元测试覆盖，为了赶上进度，可能已经太晚了（再次，单元测试完成的工作量比实际的代码更大）。

出于所有这些原因，我建议毫不犹豫地重新执行主代码版本上的单元测试。与它带来的价值相比，这只是微不足道的努力。

它将对主分支的准备情况进行最后检查，以进行发布测试阶段。此外，它将有助于发现大部分技术性错误（例如，导致源代码无法成功执行到最后的错误），从而将下一阶段仅集中在业务功能的验证上。

为功能测试做准备

所有先前的测试活动应该得出一个具体的结论——主分支代码没有技术错误，并且可以无问题地执行端到端功能流程。

这是一个可以很容易由一个人完成的阶段，而且这个人甚至不需要有技术背景。

事实上，如果这个人与开发人员没有联系，但对业务用户希望代码的行为有功能意识，那么这样做会更好。有两个主要的活动需要完成：

#1. 针对功能测试的新迭代故事

每个迭代理应该带来一些以前不存在的新功能（迭代目标的增量），因此应该进行验证。重要的是确保新的软件部分可以正常工作，以至于业务用户现在很高兴拥有它，因为他们显然至少在整个上一个迭代中都期待着它的到来：）。

当（长期的）承诺的功能最终宣布要发布时，只有在隔天发现它实际上不起作用时，这是一种非常令人沮丧的经历。

因此，正确测试新的迭代功能至关重要。为了使其成功，最好是提前收集重要的测试案例，并从相关利益相关者（无论是产品负责人还是最终用户）那里获取，并制定一个包含迭代内部所需的所有这些测试案例的列表。

乍一看，这可能让人感到不知所措，但根据我的经验，一个人完全可以胜任。由于迭代大多都相当短暂（如两周的短暂期限），所以几乎从来没有太多的新内容，因为迭代还包括额外的活动，如technical debt故事、文档、设计/探索故事等。

然后，测试案例首要目标是验证所需的功能。如果结果出现任何问题，只需联系相关的开发人员（与此特定缺陷相关的变更所有者）希望能够快速解决问题。

通过这种方式，开发人员将花费最少的时间与功能测试相关，并且仍然可以集中精力做他们最喜欢的活动。

#2. 回归测试案例执行

功能测试的另一部分是确保到目前为止的一切在下一次发布后仍然可以正常工作。这就是回归测试的用途。

回归测试的测试案例最好是定期维护和检查，以便在每次发布之前重新访问。根据具体项目的特点，最好保持测试案例简单，但覆盖大部分核心功能和贯穿整个系统的重要端到端流程。

通常，每个系统都有一些涉及许多不同领域的流程，这些流程是回归测试案例的最佳选择。

在某些情况下，回归测试甚至可以隐含地覆盖迭代中的新功能，例如，如果迭代中的新故事更改了现有流程的某个特定部分。

因此，在大多数情况下，完成回归测试和新迭代故事功能测试并不是非常复杂的，特别是如果在每次生产发布之前定期进行，并且生产发布的周期不是非常短。

坚持在每次生产发布之前进行质量保证测试

质量保证（QA）测试是在发布到生产环境之前的最后一步，通常会被视为不重要而被跳过。特别是当Scrum团队在为新内容进行积极管理时。

即使商业用户会说他们对新功能感兴趣，而不太关注保留功能或降低缺陷数量。然而，随着时间推移，这正是开发团队最终必须减速的主要原因，这样业务用户将无法得到他们所要求的。

QA测试应该由Scrum团队之外的人员执行，最好是由业务用户在一个专用环境中执行，该环境尽可能接近未来的生产环境。或者，产品负责人可以替代最终用户。

无论如何，这应该是从最终用户的角度进行的一次干净的、功能性的测试，与开发Scrum团队没有任何联系。它将呈现产品的最终视图，并可能以一种团队没有预料到的方式使用（虽然这不是一个理想的情况，但确实可能发生）。还有时间进行最后一刻的纠正。

或者，可能会变得明显的是Scrum团队对期望没有很好地理解，在这种情况下，至少我们可以就后续计划达成一致意见，仍然是在实际生产发布之前很长时间。这再次不是一个理想的情况，但仍然比在报告成功的生产发布之后承认失败要好得多。

接下来要做什么？

将这些实践应用到日常Scrum工作中，可以严肃地培养更稳定和可预测的迭代发布习惯，而不会延迟生产发布，或者花费整个迭代只为下一次发布做准备，甚至不会强迫Scrum团队中的每个人做他们不喜欢或不知道如何有效执行的事情。

但是你肯定不需要就此停止。

Performance test包含是一个需要提及的话题。这些经常被忽视或认为是不必要的，被归为“Scrum活动优化”的第一轮。然而，我一直怀疑，如果不定期检查性能，如何期望生产系统随着时间的推移而发展。

升级也意味着引入automated tests。

我已经介绍了一组自动化测试（在流水线中的单元测试）。然而，您可以完全自动化地开发全面的端到端回归测试，并在每次部署到测试环境后自行执行。这将进一步解放开发Scrum团队，但它需要一个专门的团队来开发和维护这样的自动化测试。这将成为持续的工作，因为每当生产代码发生变化时，一些现有的自动化测试可能会失效，因此必须更新它们以继续在流水线中工作。只有少数人愿意为此付出努力，但对于开发Scrum团队来说，好处将是巨大的。

这些都是超出本文范围的主题，需要找出每种测试类型的正确计划和计时方式，以便在一个迭代窗口内完成。我很乐意在下次深入讨论！