随着测试左移话题的持续发展，为了证明我们35岁以上从业者不仅仅是经验丰富，我特意研究了“测试左移”的起源。

在“开发百科”网站上，有一个关于这个词条的详细介绍 https://www./link/00653e1c588c7b4bc7e9a6be7a43a843

该网站对测试左移的起源进行了详细考证：

">随着传统瀑布模型的局限性逐渐显现，在上世纪九十年代，出现了许多新的、现已被视为经典的软件开发模式。这些模式的提出者代表人物在2001年初的美国一个滑雪场聚会上，讨论并提出了敏捷宣言“Agile Manifest”。同年年底，来自康柏公司的软件测试工程师Larry Smith提出了“Shift-left testing”这个概念，用以描述“一种更好的集成软件项目质量保证（QA）和开发部分的方法。”[百度翻译]。

https://www./link/b8516c82e38e6b34bc96330a3ba59b03

二十年后，作为后来者，我重新阅读了这篇文章。通过作者分享他在True-64项目中的个人经历，我终于理解了测试左移的真正含义。

">如果测试左移的目的是为了获得开发团队的认可，成为他们中的一员、实现内建的可测试性、将开发的测试用例自动化、让开发人员帮助运行测试用例、从开发团队获取测试环境并大幅减少自己的测试环境、减少测试用例的运行次数并确保不遗漏缺陷、发现更少的缺陷且无需记录缺陷，那么，你想要这样的测试左移吗？

然而，这样的测试左移有一个严重的问题，就是可能会让你看起来工作不饱满。作者建议你一定要与自己的测试经理和项目经理做好汇报和沟通。

在需求澄清阶段就开始编写用例

我在功能规格说明书编写的同时参与其中，因此我同时编写了测试规格说明，并在新的授权代码编写开始时就开始编写新的授权测试代码。

与开发工程师建立紧密的沟通和获得认可

通过这种方式，我与开发工程师建立了高效的面对面沟通。

我及时了解到他们担心的领域，这让我知道该在哪里集中测试。我也因此被他们所认可。他们很快意识到我也是一个有才华的工程师，我成为了团队的一员，而不仅仅是QA计划中的一个检查框。

内建的可测试性

我只需要在规格说明中注明我需要某些可选消息发送到系统日志。通过这一条，我极大地简化了测试程序，因为授权代码现在被设计为易于测试。这基本上是免费的。

可测试性是内建的，而不是后加的。实际上，它节省了如此多的努力，以至于我完成测试程序的时间远早于授权代码准备好传递给QA。

将开发的测试用例转化为自动化测试用例

我只是从开发人员那里采纳了他们常规编写的测试用例，并将其调整为自动化使用。

从开发团队获取测试环境

这里有一个机会可以避免很多麻烦：我只是开始使用开发测试系统。

我可以在这些空闲时间运行我的测试，并直接将结果报告给编码人员。

减少测试用例的运行次数

一旦正式的基础版本到来，我可以根据我在预基础版本测试中的了解，安全地取消许多测试。

一旦我知道某个补丁在单系统和集群中都正常工作，我就无需在实际的基础版本中在QA系统上以两种模式重新测试它。

如何在减少测试用例运行次数的同时确保不遗漏缺陷

这可以通过确保开发的测试系统与每个新基础版本保持更新，以及在某些关键的基础版本上进行完整的测试运行来控制，例如在Beta版本发布或首次客户发货之前的基础版本。

使用更少的测试环境

因此，对于大多数基础版本，我可以将我的QA硬件需求减少至少75%。

发现更少的缺陷，不用记录缺陷

这种系统也意味着我在QA方面很少发现缺陷，因此无需通过昂贵且繁琐的缺陷跟踪系统来报告。

当我发现一个缺陷时，我只需走到编写代码的开发人员那里，为他或她运行测试。没有繁琐的客户缺陷跟踪系统带来的额外负担，缺陷可以在分钟内修复，而过去需要几天——实际上，我常常在当天就能再次运行我的测试来验证修复。

开发人员帮忙进行测试

能够在自动化套件中精确定位测试用例意味着我可以轻松地向开发人员准确传达缺陷，他们对我和我的测试工作的熟悉意味着他们可以使用测试套件进行单元测试。

会让你显得工作不饱满

这可能会让你看起来“未充分利用”，用管理层的委婉说法，至少在你自己的QA管理层看来是这样。

通过更聪明而不是更努力地工作，你可以完成更多工作。但不要让它看起来太容易。

哪有那么多道道，不就是为了更好地工作、更好地生活吗？不信的打工人，可以自己去看原文。

https://www./link/b8516c82e38e6b34bc96330a3ba59b03