Scrum 团队测试策略的最佳实践

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

如今，大多数成功的项目都是从概念验证 (POC) 开始的，这是对一个想法的相对较小规模的评估，其中首先验证所选的技术和功能包，评估对业务用户的潜在影响，然后，一旦证明值得投资，一个完整的项目团队被分配来设计和交付功能齐全的产品并将其部署到生产中。

这是 Scrum 团队的完美案例。 团队可以快速开发原型，在每个冲刺中添加大量新功能，而业务用户可以实时观看快速进展以及如何在大约 10 个冲刺内从头开始构建想法。 它给人留下了深刻的印象（无论如何这是 POC 的主要目标），但它也有一个重要的属性——测试活动最少或没有，甚至考虑测试过程都会是一个直截了当的笑话。

在 Scrum 团队中，这不是什么有趣的活动，人们大多喜欢在没有流程的情况下进行开发的想法，这会减慢他们的速度。 这基本上是任何测试活动都会隐式执行的操作。 在我们最需要给最终用户留下深刻印象的时候，谁想要不必要的缓慢？

如果项目团队在 POC 期结束后以相同的方式继续进行，则会发生这种情况，我将其称为POC on steroids – 生产系统的规模和功能不断增长，但仍然表现得像 POC – 一个 wannabee 完整的产品隐藏的缺陷和未探索的角落案例，只等待严重的崩溃。

但在它转换到那里之前，团队将很难从 sprint 到 sprint 跟上稳定版本，因为修复滚动问题只会变得更加复杂。

这里有一些技术在我处理类似问题时被证明是有效的，我相信它们可以被命名为实施可靠测试过程的最佳实践，仍然不会过多地扰乱开发进度——因为这是我们所有人都希望成为的一个 Scrum 团队。

分散痛苦

在处理不必要的麻烦时，除了分担痛苦，我们还能从哪里开始 :)。

我的意思是制定一个计划，该计划将需要开发人员在各处进行少量的额外活动，但随着时间的推移，这将以渐进但始终如一的方式为共同目标做出巨大贡献。

#1。 为每个创建的新代码开发单元测试代码

如果你设法说服你的 scrum 团队在其“完成定义”子句中为冲刺中创建的每个新代码添加单元测试开发，那么从长远来看，这将是一项伟大的成就。

原因很明显：

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

• 这样的单元测试可以插入到自动化的 DevOps 管道中，并在每次部署到开发或测试环境时执行。 此外，管道中的指标可以轻松导出，然后用于向业务用户演示直接绑定到源代码的测试用例的覆盖百分比。

最重要的是尽快开始。 单元测试开始开发的时间越晚，开发人员在冲刺中添加它们的注意力就越分散。

• 为已经存在的代码向后开发单元测试需要付出很大的努力。 代码的某些部分可能是由其他开发人员创建的，并且当前开发人员并不完全清楚它在每个代码部分中应该如何工作的确切知识。 在某些情况下，到目前为止，向修改后的代码添加单元测试比为冲刺开发功能更改花费更多的时间（这是在冲刺计划期间肯定没有人计算的状态）。

#2。 制定在开发环境中执行单元测试所有部分的例程

即使在创建将新代码合并到 Master 分支的拉取请求之前，在开发环境中测试功能代码和单元测试代码也应该是一项标准活动。 通过这样做，将确保：

• 单元测试代码实际上对每个部分都起作用（最终它只是另一个必须验证的代码）。 这一步经常被完全跳过。 以某种方式假设，如果单元测试以任何方式插入到 DevOps 管道中，它最终将默认在某处执行和测试。 然而，这只不过是将问题推向了冲刺活动的更高层次，团队通常没有更多的时间和更多的压力来完成每个提交的故事。
• 开发人员对新功能代码进行了基本功能测试。 显然，不能期望从该测试中完全验证业务功能，但至少该测试将确认代码按照开发人员预期的方式运行（暂时忽略业务逻辑可能在开发过程中被错误理解）。

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

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

master 分支包含其他 Scrum 团队成员的更改，即使解决了冲突并且一切正常，合并和冲突解决后的代码基本上仍然是未经测试的代码，不先验证就继续发送是有风险的它仍然工作正常。

因此，这里被证明有效的只是简单地要求执行相同的单元测试——之前已经在开发环境中完成——也在从主分支代码版本构建的环境中执行。

对于开发人员来说，这可能是他们需要在生活中加入的一个额外步骤，但这并没有那么大的努力，因为在这种情况下，不必发明任何新东西——只需重新执行已经做过的事情。

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

• DevOps 管道中的自动化单元测试非常全面，它们已经涵盖了在此之上执行的整个手动测试。

虽然达到这种状态绝对是可行的，但我在现实生活中从未经历过这样的状态。 对于开发人员来说，创建如此详细的自动化单元测试可能太费时了。 产品负责人很容易无法接受让团队在这项活动上投入如此多的时间，因为这会对冲刺中交付的故事数量产生明确的影响。

但是，对 sprint 内容的偏好永远不应成为不进行单元测试甚至最小化单元测试的借口。 通过这样做，团队将再次转换到代码缺乏太多单元测试覆盖率的状态，然后要赶上来，可能已经太晚了（同样，完成单元测试的工作量比实际的工作量更大）冲刺的代码更改）。

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

它将对发布测试阶段的主分支准备情况进行最终检查。 此外，这将有助于发现大部分技术错误（例如，阻止源代码成功执行直到成功结束的错误），留给下一阶段专注于业务功能的验证。

准备功能测试

所有先前的测试活动都应得出一个特定的结论——主分支代码没有技术错误，并且端到端功能流的可执行性没有问题。

这是一个一个人就可以轻松搞定的阶段，这个人甚至不需要有技术背景。

实际上，如果这由与开发人员脱节但具有业务用户期望代码行为的功能意识的人执行会更好。 有两个主要活动需要完成：

#1。 新的冲刺故事有针对性的功能测试

理想情况下，每个冲刺都应带来一些以前不存在的新功能（冲刺目标增量），因此应对其进行验证。 重要的是要确保新软件的工作达到业务用户现在乐于拥有它的程度，因为他们显然至少在整个最后一个冲刺中都期待它:)。

当（长期）承诺的功能最终宣布发布时，这真是一种悲伤的经历，前几天才发现它实际上不能正常工作。

因此，正确测试新的 sprint 功能至关重要。 为了使其成功，最好提前收集重要的测试用例并从相关利益相关者（来自产品所有者甚至最终用户）收集，并列出其中内容所需的所有此类测试用例冲刺。

乍一看，这可能让人不知所措，但根据我的经验，它又完全可以由一个人来管理。 由于冲刺大多很短（比如两周的时间），所以它几乎从来没有太多的新内容，因为冲刺还包含其他活动，如技术债务故事、文档、设计/尖峰故事等。

然后执行测试用例，目的是首先验证所需的功能。 如果结果出现任何问题，只有相关的开发人员（拥有与此特定缺陷相关的更改的人）希望尽快解决问题。

这样，开发人员将花最少的时间进行功能测试，并且仍然可以专注于他们最喜欢的活动。

#2。 回归测试用例执行

功能测试的另一部分应该是确保到目前为止一切正常的工作在下一个版本之后也能正常工作。 这就是回归测试的目的。

如果在每次发布之前定期维护和重新访问回归测试的测试用例，则它们是最好的。 根据具体的项目细节，最好使它们保持简单，但要涵盖贯穿整个系统的大部分核心功能和重要的端到端流程。

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

在某些情况下，回归测试甚至还隐含地覆盖了冲刺中的新功能，例如，如果冲刺中的新故事正在改变现有流程的某些特定部分。

所以在大多数情况下，完成回归测试和新的 sprint 故事功能测试并不复杂，特别是如果在每个产品发布之前定期完成，并且产品发布的周期不是太小。

坚持在每次产品发布前执行质量保证测试

质量保证 (QA) 测试是发布到生产环境之前的最后一步，而且通常会因为不重要而跳过该测试。 特别是如果 scrum 团队针对新内容进行了积极的管理。

甚至业务用户也会说他们对新功能感兴趣，而不是对保留功能或保持低缺陷数量感兴趣。 但话又说回来——随着时间的推移，这就是开发团队最终不得不放慢速度的主要原因，然后业务用户无论如何也得不到他们想要的东西。

QA 测试应仅由 Scrum 团队以外的人员执行，最好由业务用户自己在专用环境中执行，该环境尽可能接近未来的生产环境。 或者，产品所有者可以在这里替换最终用户。

无论如何，从最终用户的角度来看，这应该是一个干净的功能测试，与开发 Scrum 团队没有任何联系。 它将呈现产品的最终视图，并可能以 Scrum 团队中没有人预料到的方式使用（根本不是理想情况，但它肯定会发生）。 还有时间进行最后的修正。

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

从这里下一步去哪里？

将这些实践应用到日常 scrum 工作中可以真正让你养成更稳定和可预测的 sprint 发布习惯，而不会延迟生产发布或花费整个 sprint 只是为下一个发布做准备，甚至不需要强迫 scrum 团队中的每个人做他们不做的事情也就是说，在大部分冲刺中，我真的不喜欢或不知道如何有效地完成。

但你肯定不需要在这里停下来。

性能测试包含是这里要提到的一个主题。 这些通常被忽略或被认为是不必要的，在第一轮“scrum 活动优化”中被淘汰。 然而，我一直怀疑如果不定期检查性能，人们如何期望生产系统随着时间的推移而发展。

更上一层楼也意味着引入自动化测试。

我已经涵盖了一组自动化测试（管道中的单元测试）。 但是，您可以开发完全自动化的完整端到端回归测试，并在每次部署到测试环境后自行执行。 这将进一步解放开发 scrum 团队，但需要专门的团队来开发和维护此类自动化测试。 这将成为持续不断的工作，因为每当生产代码发生变化时，一些现有的自动化测试就会变得无效，因此必须更新它们才能继续在管道中工作。 只有少数人愿意为此付出努力，但开发 Scrum 团队的好处是巨大的。

这些主题远远超出了本文的范围，并为此处提到的每种测试类型确定了正确的时间表和时间安排，以便您可以在冲刺窗口内完成。 下次我会很乐意潜水！