在所有经典街机游戏中，Whack-A-Mole可能是最令人沮丧的。您无法赢得Whack-A-Mole的游戏。每当您认为自己撞上痣时，小流氓总是会找到一种方法可以在其他地方再次弹出，而您总是落后一步。

　　在端到端测试的世界中，当我们对生产中弹出的错误进行反应性编写测试以防止它们再次出现时，我们可能会陷入Whack-A-Bug的困境。我喜欢称这种练习为Whack-A-Bug测试，因为它是一种通用方法，但很容易成为一个无休止的循环，测试人员始终落后一步。作为我们组织的领导者，我们必须想出如何向前迈出一步，致力于开发更勇敢，具有远见的E2E测试策略。

　　为什么Whack-A-Bug测试如此常见

　　质量保证团队生活在一个令人羡慕的世界中：除非出现问题，否则他们的工作基本上不会被注意。然后，他们面临解释他们不进行测试的决定的决策，特别是如果结果要花费组织金钱的话。我们听到过很多次，“为什么没有对此进行测试？” 不管是什么原因造成影响收入的错误，如果质量检查“未能”确保质量，则公司的其他领导者可能会对其加以谴责。因此，质量检查负责人和工程师承受着巨大的压力，需要他们防止错误并确保相同的错误不会多次出现在生产中。

　　在共同创建ProdPerfect之前，我曾与工厂进行过一些咨询工作。炼油厂之类的业务部门可以清楚地跟踪与收入和成本直接相关的指标，因此可以相当容易地做出与投资回报率相关的决策。在炼油厂中，您可以轻松地衡量每天生产多少桶石油，从而优先考虑进行哪些投资以增加该日产量。许多工厂对他们的行动没有看到ROI，而对工厂中发生的最新问题做出反应。但是，当他们确实承诺将工作重点放在高投资回报率改进上时，衡量结果就相当容易。

　　当您衡量组织内软件质量检查的性能时，您无法衡量以桶为单位的六个工时代码。测试代码的价值并不一致，并且每次更新对业务的影响都不同（好坏）。由于存在这种差异，很难解决多个相互竞争的优先事项：我们如何在不牺牲速度的情况下交付价值和质量？衡量速度，价值和质量的过程不够清晰，使工程师无法获得清晰的ROI协议和统一的生产率KPI。

　　尽管衡量工程性能的工作具有挑战性，并且在组织上通常还不清楚，但是对于工程师来说，执行的压力仍然存在。而且，由于质量检查团队通常会受到这种压力的首当其冲，因此，质量检查领导者经常被迫在其E2E测试策略中采取被动态度进行操作。换句话说，由于缺乏明确的优先级度量标准，许多团队都选择打Whack-A-Bug进行测试以安抚整个组织。在测试中坚持高投资回报率计划很困难，但与炼油厂一样重要。

　　Whack-A-Bug测试的谬误

　　为了挑战这种做法，我们作为领导者首先需要自问：在应用程序的某个部分中漏入的错误是否会增加在同一位置再次发生错误的可能性？我喜欢思考赌博中类似但普遍存在的谬论：如果您将老虎机拉了六次却没有中奖，这是否意味着下次您提起老虎机时，中奖的可能性更高？尽管我们的胆量可能会告诉我们其他方式，但这两个问题的答案最终都没有。

　　Whack-A-Bug测试的谬误是假设，如果我们在以前看到错误的位置创建另一个测试，则比在其他地方编写该测试更安全。根本不是因为错误发生在某个区域，所以随之而来的是，该错误再次发生在该区域的可能性增加了。Whack-A-Bug测试不是一种主动的测试策略：Whack-A-Bug测试不会将测试添加到最需要测试的应用程序区域。相反，这是一种被动的策略：我们正在测试某个区域，以应对在那里看到的错误。上周出现错误的事实并不会改变我们组织对高优先级区域进行测试的组织重点：这些区域更可能产生错误，对客户使用很重要或直接影响收入。

　　为什么Whack-A-Bug测试伤害最大的是帮助

　　Whack-A-Bug测试伤害工程组织的原因有几个：

　　它使我们无法编写优先级高的测试。在生产中出现任何错误之前，QA团队已基于某种优先级排序机制制定了测试对象的策略。当我们编写Whack-A-Bug测试时，我们会将测试写资源从其他优先级划分机制转移到Whack-A-Bug测试中。结果，我们延迟了编写未来的高优先级测试的时间。它给您的团队增加了维护负担。Whack-A-Bug测试会降低您的团队编写未来的高优先级测试的能力。每次编写E2E测试时，您都致力于维护该测试。这将产生固定的，不可避免的持续工作水平，从而降低您用相同数量的工程师编写更多测试的能力。我见过的大多数团队都试图通过简单地雇用更多人来弥补这一点。这会减慢显影剂的生产率和速度。在连续交付过程中，每个新的E2E测试都会增加测试套件的运行时间，从而延长您的回归周期。如果您的测试套件需要花费半小时的时间来运行，并且每次提交都在运行，则意味着1）开发人员在这段时间内不生产任何东西，或者2）您的开发人员较少签入代码，因为他们没有不想等待测试运行（或同时运行）。在这两种情况下，您都将失去开发人员的工作效率，并为每个构建版本提供较少的质量反馈，这意味着每次Whack-a-Bug增量测试都会消耗开发人员的速度。它会使您的测试套件膨胀，并增加不稳定性。在某个时候，您的测试套件将变得足够大，以至于很有可能由于不稳定而在给定的运行中失败。一旦不稳定达到一定的临界值，测试套件就会频繁失败，以至于开发人员不再。发生这种情况时，它开始提供负值：增加部署运行时间而不增加质量。修复Whack-A-Bug测试的损坏

　　我们如何扭转Whack-A-Bug测试的损害？首先，我们的组织需要通过空白练习重新检查我们的测试选择。我们必须自问：如果我们要重新从头开始制定这项策略，我们的测试重点是什么？我们将测试什么以平衡测试覆盖范围与速度，维护负担和稳定性？定义了最适合我们进行测试的内容之后，我们需要将该前景覆盖在当前正在测试的内容上。这是困难的部分：我们需要有勇气关闭与该策略不符的测试。我们需要继续前进。

　　在此过程中，一个有用的帮助是评估套件中已有6个月或更长时间的测试并进行检查：最近6个月中是否捕获了任何错误？如果没有，您的团队应该强烈考虑退休，因为他们可能不值得优先考虑。除非您致力于测试各种可能的行为排列，否则必须重新设置优先级。通过此练习，我们了解到，大多数Whack-A-Bug测试实际上从未捕获到错误。面对组织的政治压力，Whack-A-Bug测试可能会给我们短期的安慰。但是，当我们让数据说话而不是人为冲动时，我们发现在绝大多数情况下，编写Whack-A-Bug测试几乎没有提供任何实际的商业价值。

　　最终，从头开始制定新的测试策略以突出您最重要的优先事项，这将释放您的开发人员和质量检查资源，以正确涵盖对您的业务真正重要的内容。好处是三方面的：1）更好的质量，2）更好的速度和成本，以及3）测试套件中开发人员的信任度更高。

　　分享对更好的质量检查的承诺

　　许多QA团队诉诸Whack-A-Bug测试，因为他们承受着应对产品质量问题的压力。只有当我们组织中的所有领导者都共享并履行坚持团队QA策略的承诺，而不是在每次出现问题时都m之以鼻时，更好的QA做法才有可能。

　　首先，对于工程和产品负责人，与质量检查负责人一起认识到Whack-A-Bug测试不一定能改善质量保证至关重要。我们必须了解，某个地方出现的错误并不一定会改变测试内容的优先级。我们的领导者必须坚持在速度，生产率和质量保证之间建立明确的权衡机制的承诺。每个组织的权衡都是不同的，并且会随着时间而变化，但是在任何给定时间都必须保持神圣。当我们看到代码中的错误时，我们需要承诺：“我们需要重新考虑我们的战略，还是可能需要重新考虑我们的折衷点？我们是否在优先考虑正确的方法？我们是否在正确地做出承诺？可接受的测试水平看起来如何？我们的测试方法将如何过度负担我们的团队？”

　　在ProdPerfect，我们彼此的承诺是我们在确定质量检查优先级时不会做出反应。我们邀请您加入我们的承诺中：我们不会因膝下意识的反应而立即对每个错误进行测试。相反，我们将从错误中学习。我们将通过监督漏洞在何处滑出以及它们所造成的损害，在一段时间内对它们进行评估。然后，我们将做出以数据为依据的决策，以告知我们的测试策略。我们将共同承担更改测试策略的后果和成本。但是，我们不会通过测试方法来对Whack-A-Bug做出反应。

　　做出这一承诺需要所有人的组织纪律和勇敢的领导。我们所有的领导者都必须同意将质量保证视为一种伙伴关系，在这种伙伴关系中，组织需要有效地平衡其测试优先级并确定业务的最佳覆盖范围。我们每个人都能从做出这样的承诺中受益，我邀请您与我分享这一承诺。与其通过被动的Whack-A-Bug测试来加重我们的流程和团队的工作量，不如让我们通过主动思考并让数据独自推动我们的测试策略来对它们进行良好的照顾。