如今，“数字化”已成为商业活动各个方面的关键部分，快速交付创新的能力是生死攸关的。在竞争激烈的市场中，客户对体验的期望越来越高，及时发布一流的数字产品和服务不再是一种奖励，而是客户获取和保留的基础。最微小的延迟可能是竞争对手获得市场份额并成为新颠覆者的机会。
这使得授权软件团队以速度和规模提供完美的数字体验具有重要的战略意义。为了实现这一点，组织需要反馈来确定最新开发是否会按预期运行、破坏核心功能，甚至更糟的是，在现实环境中失败。软件测试曾被视为速度和创新的障碍，现在已成为开发活动的重要组成部分。
这代表着软件开发领域从传统的瀑布式方法向软件开发的巨大转变，在瀑布式方法中，测试通常被留到最后。现在，转向DevOps和敏捷方法意味着测试对于加速创新应用程序的交付至关重要，而不会产生不可接受的业务风险。但敏捷和DevOps计划也将传统测试方法推向了极限。整个开发生命周期的自动化和测试是新的必备条件。
组织发布的频率越来越高，甚至每小时发布多次。测试人员需要在实施每个用户故事后立即对其进行测试，即使该功能与同时开发的其他功能交互也是如此。当更改无意中影响了前几周、几个月或几年实施、测试和验证的旧功能时，测试人员还需要提醒团队。
随着组织越来越多地采用自动化交付管道实现持续交付，是否继续进行最终将取决于测试结果。测试自动化是必需的，但还不够。即使采用最全面的自动化，也没有足够的时间来测试所有内容。当组织采用现代架构和交付方法时，即使是经历了明显测试自动化成功的团队也会面临挑战。
例如，无法以足够快或足够频繁的速度创建或执行现实测试。团队被看似永无止境的误报和不完整测试所淹没——更不用说解决这些问题所需的所有测试维护。最后，他们无法自信地告诉业务主管发布候选版本是否适合发布。
每次组织准备发布新版本时，都不可能测试现代业务应用程序的所有可能路径。但是，如果重新考虑测试方法，就有可能用比大多数公司目前进行的测试少得多的测试来实现对业务风险的全面评估。