Scrum 迭代中的测试策略：摆脱“类固醇 POC”
现今，许多成功的项目都始于概念验证（POC），这是一种对想法进行小规模评估的方法。它首先验证选定的技术和功能，然后评估对业务用户的潜在影响。如果结果证明值得投资，则会分配一个完整的项目团队来设计、交付功能完善的产品并部署到生产环境中。
对于 Scrum 团队而言，这似乎是一个理想的场景。团队能够快速构建原型，在每个迭代中添加新功能，业务用户则可以实时观察进展，并了解如何在相对较短的时间内（例如，10个迭代周期）将想法从概念转化为现实。虽然这无疑令人印象深刻（毕竟，这是POC的主要目标），但也存在一个关键问题：测试活动极少甚至没有，或者说，认真考虑测试流程会被视为一个玩笑。
在Scrum团队中，测试往往不受欢迎，许多人更喜欢在没有流程约束的情况下进行开发，认为流程会降低速度。这基本上是任何测试活动可能带来的影响。当我们最需要给最终用户留下深刻印象时，谁会想要不必要的减速呢？
如果项目团队在POC阶段结束后仍以同样的方式运作，问题就会出现。我称之为“类固醇POC”：生产系统的规模和功能不断增长，但其本质仍然像一个POC——一个带有隐藏缺陷和未探索角落的半成品，随时可能发生严重崩溃。
在这种情况下，团队将难以维持从一个迭代到下一个迭代的稳定版本，因为修复不断出现的问题变得越来越复杂。
以下是一些我在处理类似问题时发现有效的技巧。我相信它们可以被视为实施可靠测试流程的最佳实践，同时不会过度干扰开发进度。毕竟，我们都希望成为一个高效的 Scrum 团队。
分散测试压力
处理麻烦事时，除了分摊压力，还能从何处着手呢？我的意思是制定一个计划，让开发人员在各处进行少量的额外工作。随着时间的推移，这些额外工作将以渐进但持续的方式为整体目标做出重要贡献。
#1. 为每个新代码段编写单元测试代码
如果你能说服你的Scrum团队在其“完成定义”中加入为每个迭代中创建的新代码编写单元测试这一项，那么从长远来看，这将是一项重大成就。
原因显而易见：
- 它将迫使开发人员思考代码的各种非标准路径。
- 这些单元测试可以被集成到自动化的 DevOps 管道中，并在每次部署到开发或测试环境时执行。此外，管道中的指标可以轻松导出，用于向业务用户展示与源代码直接关联的测试用例的覆盖率百分比。
最重要的是尽快开始。单元测试开始得越晚，开发人员在迭代期间添加它们的注意力就越分散。
- 为现有代码追溯开发单元测试需要付出巨大的努力。代码的某些部分可能由其他开发人员编写，当前的开发人员可能并不完全清楚每个代码段的具体工作原理。在某些情况下，为修改后的代码添加单元测试所花费的时间甚至比在迭代期间开发功能变更所花费的时间还要多（这绝对不是在迭代计划期间会被考虑到的情况）。
#2. 在开发环境中例行执行所有单元测试
即使在创建将新代码合并到主分支的拉取请求之前，在开发环境中测试功能代码和单元测试代码也应该是一项标准活动。这样做可以确保：
- 单元测试代码实际上对每个部分都有效（毕竟，它只是另一段需要验证的代码）。这一步经常被完全跳过，人们会想当然地认为，如果单元测试被集成到 DevOps 管道中，它最终就会在某个地方被执行和测试。然而，这只不过是将问题推到了迭代活动的更高层级，团队通常在那里没有更多的时间，并且有更大的压力来完成每个提交的故事。
- 开发人员对新的功能代码进行了基本的功能测试。显然，不能指望通过此测试完全验证业务功能，但至少可以确认代码按照开发人员预期的那样工作（暂时忽略业务逻辑可能在开发过程中被误解的情况）。
#3. 合并代码到主分支后执行单元测试
在本地分支上拥有功能代码（除了分支所有者之外，没有人正在开发新功能）是一回事，但在拉取请求之后让相同的代码工作并合并到主分支中是完全不同的事情。
主分支包含了其他Scrum团队成员的更改。即使冲突已解决并且一切看起来都正常，合并和冲突解决后的代码基本上仍然是未经测试的代码。在没有事先验证它是否仍然正常工作的情况下，就继续将其发送是很冒险的。
因此，一个被证明有效的方法是，要求在从主分支代码版本构建的环境中也执行相同的单元测试（之前已在开发环境中完成）。
对开发人员而言，这可能是在其工作中需要添加的一个额外步骤，但这并不是什么大的负担，因为无需发明任何新事物，只需重新执行之前完成的操作即可。
在特定情况下，可以跳过此步骤：
- DevOps 管道中的自动化单元测试非常全面，它们已经涵盖了在此之上执行的整个手动测试。
尽管达到这种状态绝对是可行的，但在现实生活中我从未遇到过这种情况。对于开发人员来说，创建如此详细的自动化单元测试可能需要花费太多的时间。产品负责人很容易无法接受团队在此活动上投入如此多的时间，因为它会对迭代中交付的故事数量产生明显的负面影响。
但是，对迭代内容的优先考虑绝不应成为不进行单元测试或尽量减少单元测试的借口。这样做，团队将再次陷入代码缺乏足够的单元测试覆盖率的状态。如果那时想要弥补，可能已经为时已晚（同样，完成单元测试的工作量将大于迭代中的代码更改）。
基于以上所有原因，我建议毫不犹豫地在主代码版本上重新执行单元测试。与它将带来的价值相比，这只需要付出很小的努力。
这将对发布测试阶段的主分支准备情况进行最终检查。此外，这将有助于发现大部分技术错误（例如，阻止源代码成功执行的错误），从而使下一阶段可以专注于业务功能的验证。
准备功能测试
所有之前的测试活动都应该得出这样的结论：主分支代码没有技术错误，并且端到端功能流的执行没有问题。
这一阶段可以由一个人轻松完成，这个人甚至不需要有技术背景。
实际上，如果由一位与开发人员脱节但对业务用户期望的代码行为具有功能意识的人来执行会更好。 有两个主要活动需要完成：
#1. 针对新的迭代故事进行功能测试
理想情况下，每次迭代都应该带来一些以前不存在的新功能（迭代的目标增量），因此应该对其进行验证。 重要的是要确保新软件的工作达到业务用户期望的程度，因为他们至少在整个上一个迭代中都在期待它。
当（长期）承诺的功能最终宣布发布，但几天后才发现它实际上不能正常工作时，这真是一种令人沮丧的经历。
因此，正确测试新的迭代功能至关重要。 为了使测试成功，最好提前收集重要的测试用例，并从相关的利益相关者（包括产品负责人甚至是最终用户）处获取，并列出迭代中需要验证的所有测试用例。
乍一看，这可能让人感到不知所措，但根据我的经验，完全可以由一个人来完成。由于迭代通常都很短（例如两周），并且迭代中还包括其他活动（如技术债务故事、文档、设计/尖峰故事等），所以通常不会有太多的新内容。
然后执行测试用例，目的是首先验证所需的功能。如果结果出现任何问题，则只有相关的开发人员（负责特定缺陷的更改的人）希望尽快解决问题。
通过这种方式，开发人员将花费最少的时间进行功能测试，并且仍然可以专注于他们最喜欢的活动。
#2. 执行回归测试用例
功能测试的另一部分应该是确保到目前为止正常工作的功能在新版本之后也能正常工作。这就是回归测试的目的。
如果在每次发布之前定期维护和重新访问回归测试的测试用例，那么回归测试的效果将是最佳的。 根据具体项目情况，最好保持回归测试的简单性，但要覆盖贯穿整个系统的大部分核心功能和重要的端到端流程。
通常，每个系统都有涉及许多不同领域的流程，这些是回归测试用例的最佳候选者。
在某些情况下，回归测试甚至还隐含地覆盖了迭代中的新功能，例如，如果迭代中的新故事正在修改现有流程的某些特定部分。
因此，在大多数情况下，完成回归测试和新迭代故事的功能测试并不复杂，特别是在每次产品发布之前定期完成且产品发布周期不太短的情况下。
坚持在每次产品发布前执行质量保证测试
质量保证 (QA) 测试是发布到生产环境之前的最后一步，并且通常会因为它不重要而被跳过。尤其是当 Scrum 团队积极管理新内容时。
甚至业务用户也会说他们更关心新功能，而不是现有功能的保留或保持较低的缺陷数量。 但反过来，随着时间的推移，这正是开发团队最终不得不放慢速度的主要原因，而业务用户最终无论如何都无法得到他们想要的东西。
QA 测试应仅由 Scrum 团队以外的人员执行，最好由业务用户自己在专用环境中执行，该环境尽可能接近未来的生产环境。或者，产品负责人可以在这里代替最终用户。
无论如何，从最终用户的角度来看，这应该是一个与开发 Scrum 团队没有任何联系的纯粹的功能测试。 它将展示产品的最终视图，并可能以 Scrum 团队中没有人预料到的方式被使用（这当然不是理想的情况，但肯定会发生）。 还有时间进行最后的修正。
或者，很明显 Scrum 团队没有很好地理解期望。在这种情况下，至少我们可以在实际生产发布之前就后续计划达成一致。 这也不是一个理想的情况，但仍然比在报告成功的产品发布后立即承认失败要好得多。
下一步该怎么做？
将这些实践应用到日常 Scrum 工作中，可以真正帮助你养成更稳定和可预测的迭代发布习惯，而不会延迟生产发布或花费整个迭代仅仅为下一个发布做准备。同时，也不会强迫 Scrum 团队中的每个人去做他们不喜欢或不擅长的事情。
但你肯定不需要止步于此。
性能测试是这里要提到的一个重要主题。这些测试通常被忽略或被认为是不必要的，在第一轮“Scrum 活动优化”中被剔除。 然而，我一直怀疑，如果不定期检查性能，人们如何期望生产系统随着时间的推移而得到改进。
更进一步也意味着引入自动化测试。
我已经提到了一组自动化测试（管道中的单元测试）。 但是，你可以开发完全自动化的端到端回归测试，并在每次部署到测试环境后自行执行。 这将进一步解放开发 Scrum 团队，但需要专门的团队来开发和维护此类自动化测试。 这将是一项持续的工作，因为每当生产代码发生变化时，一些现有的自动化测试就会失效，必须更新它们才能继续在管道中工作。 只有少数人愿意为此付出努力，但对于开发 Scrum 团队来说，好处是巨大的。
这些主题远远超出了本文的范围。 确定此处提到的每种测试类型的正确时间表和时间安排，以便在迭代窗口内完成，也是一个值得探讨的问题。 下次我很乐意深入研究这些内容！