当测试被推迟时该如何处理

编译整理｜TesterHome社区

作者｜Dennis Martinez

如今的软件公司，尤其是初创公司，倾向于快节奏的环境，专注于尽快推出产品。技术进步导致对快速开发和频繁交付客户的需求增加。不幸的是，这种激烈的节奏也导致团队为了实现交付目标而放弃某些事情。猜猜最先被搁置的领域是什么？

如果你在这些公司工作或曾经在这些公司工作过，就会知道测试通常是开发计划中首先被搁置的事情之一。我作为开发人员和测试员的整个职业生涯都在初创公司工作——最大的公司员工总数不到 50 人。在超过 19 年的职业生涯中，我看到太多项目计划将 QA 和测试搁置一旁，通常是在出现延误的第一个迹象时，或者当组织注意到竞争对手在同一领域开发类似产品时。

陷入这种陷阱的不仅仅是小型初创公司或公司。各种规模的组织都曾经历过跳过测试的后果。一些例子是微软的 Xbox 360 视频游戏机在2008年的早期故障率高达30%，三星的 Galaxy Note 7 手机由于未发现缺陷而导致电池爆炸。匆忙推出一个有缺陷的 Web 应用程序是一回事。然而，当你的公司因为匆忙完成 QA 流程而损失数十亿美元时，它提醒了每个人充分测试的重要性。

有时，跳过测试也是可以的

作为一个对软件质量痴迷的人，这种尽快推出新功能的习惯让我感到担忧，因为我注意到这种习惯正在兴起。在大多数情况下，推迟产品所需的测试是项目管理不善、工作流程效率低下或其他不能成为跳过 QA 的理由。现在尝试节省时间是一种简单的出路，尽管节省的时间通常会在最不合时宜的时候给团队带来麻烦。我们都有过这样的时刻，为了节省几分钟而忽略了一件小事，但之后却需要花费数小时来处理它。

然而，从务实的角度考虑，我可以理解为什么公司有时会选择减少测试时间。对于努力维持业务运转的小型企业来说，时间是他们拥有的最宝贵的资源之一（如果不是最宝贵的话）。比竞争对手更快地将产品推向市场可能会成为公司兴旺发达与倒闭之间的区别。如果今天绕过一些测试可以确保公司明天能够生存，那么这是理所当然的。

但是，这种权衡有一个警告。只有在测试是暂时的，并且很快就会恢复常规测试实践的情况下，绕过测试才有意义。大多数组织在产品开发的一两次迭代中都忽略了测试，这就是他们失败的地方。有可能跳过一两次测试不会导致任何问题，应用程序会顺利运行。这会让开发团队产生一种虚假的安全感—— “嘿，即使我们没有测试，一切仍然有效。也许我们根本不需要在 QA 上花费太多时间！”然后有一天……砰的一声，一个巨大的错误让生产系统瘫痪了，每个人都手忙脚乱地修补团队本可以在它成为麻烦之前检测到的东西。

如何处理延期测试

假设你发现自己处于这样一种情况：团队为了赶上最后期限、领先于竞争对手或其他合理的情况而推迟 QA。在这种情况下，你最终仍然可以重新开始。你的组织可以采用不同的策略来减轻在部署前没有进行充分测试的短期风险。以下是可以在开发和测试团队中建立的一些实用技巧：

将测试视为部署后的项目

虽然你无法在发布之前对应用程序进行全面测试，但这并不意味着无法在发布后对其进行测试。测试不是“现在或永远”的情况，而是一个持续的过程。利益相关者通常会在开发阶段花一些时间来验证项目的状态，以确保公司花时间为产品构建正确的东西。理想情况下，这不仅应该在发布之前进行，也应该在发布之后进行。

我在软件开发团队中看到的一个反复出现的问题是，在一次大型发布之后，所有的测试都会戛然而止，直到下一个重大事件出现。即使在最忙碌的初创公司，部署后的几天或几周内，测试速度也会放缓，然后逐渐加速进入下一个周期。这是有道理的，因为大型发布前的几周压力很大，团队应该有时间放松一下，为下一步做准备。然而，在发布后放慢或停止所有测试是一个巨大的错失机会。有时，在这段停工期间进行测试效果更好，可以提高质量，因为最后期限前的压力实际上已经消失了。

一个好的做法是将测试视为团队内部的独立项目，在发布后进行处理。就像项目经理创建票据来跟踪团队即将开展的工作一样，QA 可以创建自己的问题集，以提醒自己他们忽略了哪些领域，以及部署后需要进一步测试的领域。这种做法将帮助你安排必要的时间来完成在开发高峰期间无法完成的工作，并让团队的其他成员了解由于缺乏彻底的测试而可能在未来出现问题的领域。

观察并收集现实世界的反馈

你可能听过这句名言：“没有作战计划能在与敌人接触后幸存下来。”在软件开发和测试中，你可以将这句话改写为：“没有测试流程能在与现实世界接触后幸存下来。”无论你在发布前计划或测试了多少，生产环境中总会有意外问题出现。在开发过程中，如果跳过充分的测试，你可能会遇到更多缺陷，但这并不意味着在产品发布后失去了修复它们的机会。

了解应用程序是否可靠，最好的方法就是在实际生产中使用它。但是，要获取这些信息，需要建立系统来提供所需的洞察力，以解决发布前测试较少导致的任何问题。以下是一些有用的示例工具和服务：

• Sentry和Honeybadger等异常处理服务会立即向开发人员发出应用程序代码中的错误警报。

• Datadog和New Relic等监控工具可以显示应用程序性能的实时情况。

• Grafana和Prometheus等可观察性工具可收集基础设施的数据，从而进一步洞察整个系统。

在高峰期测试你能测试的内容

我们大多数测试人员都知道，为了赶进度而匆忙完成开发过程，几乎没有进行任何实际测试，这样做的后果是严重的。当面临迫在眉睫的最后期限时，很难相信自己能抽出哪怕一丁点额外的时间来提高质量。尽管如此，即使在冲刺中期或快结束时完成任务的压力越来越大，也必须记住，即使你很着急，也不应该完全放弃测试。

在大多数组织中，当事情很紧急时，团队不会有太多时间进行测试自动化，因为它会带来额外的挑战，可能会进一步影响项目的进度。这意味着我们应该在这些时期更多地强调手动和探索性测试。它允许 QA 以外的其他团队成员在日常工作中进行一些快速验证，这通常会产生非常有价值的见解，最终带来更高质量的产品。

我知道，在截止日期迫在眉睫的情况下进行充分的测试说起来容易做起来难。但是，即使日程安排中没有专门的时间，团队也可以并且应该鼓励在一天中尽可能多地进行测试。当测试作为整个团队的持续活动进行时，它会大大增加及早发现问题的机会，并在周期结束时的混乱中保持产品稳定。即使无法完成全部测试，做点什么也比什么都不做要好。

概括

如今，每家公司都希望尽快开发和部署其产品。然而，强调尽可能快的发布周期往往会导致糟糕的测试实践，因为 QA 是首先被抛弃的事情之一。如今，当项目进度面临延误的危险时，软件测试似乎成为第一个被砍掉的事情。开发人员和测试人员通常承受着持续的压力和紧迫的时间表，没有时间或精力来验证正在以高质量标准完成的工作。

如果在发布前没有足够的时间进行测试，请不要担心。你和你的团队在产品发布后仍可以帮助提高质量。考虑设置一个专注于 QA 的部署后项目，以优先处理跳过的测试。请记住，即使你很着急，进行一些手动或探索性测试也比根本不进行测试要好。

当前的“快速失败”心态有时会成为推迟或完全绕过测试的借口。不过，有时跳过测试到稍后进行也是有意义的，特别是如果它能让你的业务继续发展的话。然而，关键是要将其作为一次性决定，而不是组织的默认行为。通过在组织中保持健康的测试行为并制定部署后测试计划，你将能够在最繁忙的环境中保持产品质量。（原文链接：https://dev-tester.com/how-to-deal-with-testing-when-its-pushed-to-later/）