在 2018 年秋季在线测试会议上，Brendan Connolly 指出回归测试的自动化并非总是最佳的解决方案。由此，他提出了“手动回归测试宣言”（Manual Regression Testing Manifesto），并展示了如何利用该宣言区分功能测试和回归测试，以及决定测试是否需要自动化。
Brendan Connolly 在 2018 年秋季举行的在线测试大会上提出，回归测试的自动化并非总是最佳的解决方案。由此，他提出了“手动回归测试宣言”（Manual Regression Testing Manifesto），并展示了如何利用该宣言区分功能测试和回归测试，以及决定测试是否需要自动化。
手动回归测试宣言参照了敏捷宣言的理念。它是针对测试目的的公开宣言，也是用于讨论测试质量、探索测试人员贡献方式的框架。
Connolly 指出，人们通常认为“测试”问题（尤其是回归测试问题）似乎需要一些“银弹”（即某种极端有效的方式）才能解决，例如购买适用的工具、自动化全部测试、引入人工智能解决方案等。在 Connolly 看来，这些做法并非完全没有价值，只是我们是在尝试使用瀑布式软件开发时期人们所反对的那种说明性的测试方法。
手动回归测试宣言提出了以下五个理念：
- 行为高于缺陷；
- 一致性高于正确性；
- 实现高于意图；
- 整合性高于复杂性；
- 共识高于完备。
Connolly 指出，与敏捷宣言一样，并不是说右边的部分没有价值，只是我们更注重左边的部分。
Connolly 说，敏捷革命展示了沟通和协作的价值，而不是让人们采用更多的流程和工具。测试和 QA 领域也是一样，只是实现起来很难，因为测试过程是环环相扣的，难以用适当的用语描述它。
Procore Technologies 公司高级质量工程师 Brendan Connolly 在 2018 年秋季的在线测试大会上做了演讲。在演讲结束后，InfoQ 采访了 Connolly。
InfoQ：为什么我们需要手动回归测试宣言？
Brendan Connolly：传播促成我们成为测试人员的技能和意图是展示价值的关键，而颇具挑战之处在于如何表达测试及其预期产出在整个软件开发生命周期中是如何变化的，以及为什么会发生这些变化。
回归测试是测试人员和管理人员常会产生误解的一个领域。通常的建议是通过自动化消除此类痛点，但并非所有的场景都能自动化，或是存在投资回报率不佳的问题。这是因为有些回归测试并不适合进行自动化。因此，为了能清晰明了地开展交流，我认为制定公开宣言会有所帮助。
InfoQ：如何解释“行为高于缺陷”（Behavior over Bugs）这一理念？
Connolly：如果测试人员未找出软件缺陷，他们就很难有为项目作出贡献的成就感。对于测试新手尤为如此。
功能测试是深挖问题和错误的时间。回归测试旨在最大限度降低中断，我们并不希望新功能对已有功能产生意外的中断。一旦测试人员开始回归测试以便查找错误，那么他最终需要花费大量的时间重新测试功能。根据我的经验，这更有可能发现一些与最新的代码变更毫不相干的小问题，也可能会重新发现一些团队曾经选择忽略的旧问题。
即便测试人员发现了一个缺陷，除非是一个严重的缺陷，并且与当前的变更切实相关，否则只是在引入干扰。任何在回归测试过程中发现的错误都需要根据版本的发布压力做出权衡。这可能会降低测试人员在团队中的信任度，因为人们会认为测试人员似乎更专注于发现软件缺陷，而不是如何向客户提供新功能。
更为重要的是，我们应确保在做出变更时，客户所期望和依赖的行为仍然存在。
InfoQ：如何解释“共识高于完备”（ Common over Complete）这一理念？
Connolly：在测试人员职业生涯的某个时刻，他们都会被问及他们是否测试过所有的东西。事实上，对于任何一个项目，测试人员必定会做出一些权衡。测试人员所做的是尽量在可用的时间内最大程度地降低风险。
回归测试并非要确保所有的边界条件都经过验证，也并非意在确保可用性、性能或安全性。虽然这些方面都十分重要，但这些测试不应该发生在版本发布之时。
一旦测试人员接受了完备测试这一重担，也就承担了各种责难。作为测试人员，我们需要将讨论引导到如何制定一套完整的策略，即如何用回归测试组件确保客户的核心体验与设计的一样。
InfoQ：如何使用该宣言改进手动回归测试？
Connolly：手动回归测试宣言提供了多项内容。首先，它给出了区分回归测试和功能测试的明确界限，这通常是测试人员和管理层所面临的一个挑战。 宣言的每个核心原则都聚焦于两个具备价值的测试要素上。通过对比两个要素的相对价值，我们就可以定义整个发布周期的测试期望。我们并不是要区分两个要素孰优孰劣，而是给每个要素一定的时间和空间，让测试人员去指出其中的差异。
其次，宣言提供了一个用于讨论测试质量、探索测试人员贡献方式的框架。人们很容易将测试人员视为恶意的软件破坏者，而实际上，我们可能会和软件开发人员一样甚至比他们还要喜欢我们所测试的软件。为确保软件正常运行，即便我们与开发人员之间毫无联系，我们也会花费大量时间测试代码。团队花了大量时间讨论代码标准和实践，但是代码本身比测试和质量更加真实和可度量。测试人员之间并不存在什么公共语言，所以，每个测试人员都必须能够表达代表自身动机的想法。
我希望该宣言能激发测试人员去思考目前在做的事情，搞清楚质量对他们以及处于软件开发生命周期不同阶段的团队来说意味着什么。这样他们就能够更轻松地表达他们想要完成的事情，然后更好地向团队提出问题。
评论