当测试会议的世界正在讨论“左移”（Shift Left）——一种让我们的努力更有成效、而不是制造失败需求的重要运动时，我们注意到了另一个转变： “下移”（Shift Down） 。

多年来，我们一直在讨论这样一个理念：要在程序化测试领域取得可持续的成功，你需要以不同的方式分解测试。为了测试目的而构建的优秀自动化，很少是通过自动化你认为人类体验的端到端流程来实现的。优秀的自动化优化了速度和反馈的准确性，以及时间和位置的细粒度——对于做出影响性更改的开发者而言，立即可用。不对问题来源进行猜测可以节省大量精力。

今天，当我在一场关于如何在测试中应用当今 AI 的演讲中谈到这两个转变时，我认为我们应该首先“左移”和“下移”，并且我个人猜测，在这些转变之后，我们可能会喜欢 AI 为我们所做的事情。我也意识到，将组织定位在这两个位置有助于理解他们所自动化的工具和工作流程理念。

​​

我们所说的“下移”是什么？ “左移”是一个常用术语，但我更倾向于没有左或右，而是通过单次提交交付，使事情变得连续。这是一个美好的愿景。但“下移”，却不那么常被讨论。

​​

“下移”是这样一个理念：测试驱动开发（TDD）很好，但受限于个人开发者的意图。 许多开发者在表达和捕捉这种意图方面很优秀，并且每天都在进步。拥有这种意图在日常接受或拒绝现代工具生成的代码以及选择保持控制方面非常有益。根据一组肯定不是用 TDD 构建、单元测试程度未知的项目样本，我们看到一份报告称，在我们所有努力之后仍然流入生产环境的缺陷中，有 77% 可以事后通过单元测试重现，这意味着在单元测试层面上还有很大的潜力来做好测试工作。我喜欢使用“探索性单元测试”这个词，这有点像在代码的上下文中，通过学习来扩展当前的意图，以找出这 77% 中的一些问题。

对于我有幸合作的少数工匠而言，测试驱动开发和探索性单元测试可以互换。对于其他人来说，后者鼓励我们花时间找出差距，特别是对于遗留代码，那些在我们之前的人没有留下足够完整的测试来捕捉他们的意图。

“下移”推动了对单元测试、组件测试、子系统测试的讨论，并指导我们为分解的反馈进行设计。 我们在这个转变上已经有很长时间了，就像另一个转变一样。