Shift-left是一种软件开发方法，在生命周期的早期执行测试，在项目时间轴上向左移动。 向左移动并不仅仅指动态测试或实际运行系统; 它也可以指静态测试，因此它也意味着进行评审和检查，以及更多的单元和集成测试，而不是基于GUI的测试。

在敏捷或DevOps环境中，它通常意味着尽早测试软件的一小部分，而不是在sprint结束时进行测试。 从这个意义上讲，左移和连续测试部分地涉及相同的目标和实践，尽管连续测试更侧重于自动化。 测试驱动开发（TDD）和行为驱动开发（BDD）也可以是左移的实现。

向左移动的原因有很多，包括防止项目延迟，缩短交付周期，发现隐含要求以及尽早发现错误。 本文将介绍一个大型组织的案例研究，该组织将其测试结果转移，其团队成员采用的实际测试技术，遇到的挑战以及他们如何找到成功。

案例研究的背景

本文所基于的左移的实现是在一个大型金融机构中进行的。 该组织必须在其软件中实施法律和法规，并且这些实施具有固定的生产期限。 该组织正在从瀑布式开发方法过渡到敏捷/ SaFE软件开发。 开发工作由一个多功能团队组成，有四名分析师，两名开发人员和一名测试人员，他们正在研究计算个人付款的组件。

团队经常遇到的一个问题是团队之间共享测试环境的可用性。 该团队不是测试环境的唯一用户，并且要测试的功能通常与测试环境中安装的软件分支或版本不同。 由于它是一个共享环境，您不能只安装测试所需的版本，因为测试环境的其他用户可能正在运行他们首先需要完成的测试。 这意味着团队在等待其他团队时的空闲时间。

为了满足最后期限，团队必须具有创造性，看看他们是否可以加速测试，或者至少在测试环境可用之前最大限度地减少空闲时间。

在实践中向左移动

在常规冲刺期间，该团队迈出了向左移动的第一步，用于软件发布。 测试设计与开发平行，并且都基于分析师提出的要求和规范。 （这也是在传统的瀑布项目环境中完成的，左移也可以毫无问题地使用。）测试设计在测试场景中详细阐述，测试场景中记录了测试管理工具。

在此之后，团队通常不得不等待开发人员将他的更改提交到存储库以及在测试环境中部署软件。 但是，由于测试环境可用于我们团队的时间以及另一个团队在测试环境中部署的更改，团队面临着比预期更长的等待时间。

但测试环境不是这些问题的主要原因。 主要原因是多个团队在没有分布式版本控制的同一代码库中工作，这使得专门测试您正在进行的更改而不是该软件构建中的所有开发人员的组合更改具有挑战性。

为了尽可能地花费空闲时间，开发人员和测试人员决定在软件提交到软件存储库之前在开发环境中本地运行测试。 通常，这不符合独立测试的原则; 此外，本地开发环境与测试环境不同。 但是，由于在不同配置上运行而导致的风险被认为是最小的，因为在测试环境中的每个软件交付之后也会运行集成测试。

测试环境应尽可能接近生产配置，以确保这些因素不会影响应用程序的功能或行为。 但是团队决定对开发环境进行初始测试，并在测试环境可用后对测试环境进行回归测试。

这种工作方式产生了一些后果。 首先，它意味着我们需要确保开发环境能够运行测试。 测试由该项目中使用的测试工具执行，该测试工具是由测试人员自己开发的内部开发的专有测试工具。 测试工具需要在开发人员的计算机上本地运行，以便测试人员可以上载并运行测试用例。

其次，这意味着团队需要尽量减少潜在的双重工作。 在开发人员的笔记本电脑上运行意味着与测试服务器（即本地与整体测试环境）相比，运行在不同的配置上，这意味着您必须进行两次测试以确保配置问题不会导致不同的测试结果。 为了解决这个问题，我们在运行测试后直接自动化测试，并确保它们将包含在每次提交后在持续集成构建中运行的回归测试集中。 这意味着我们只需要执行两次测试：一次手动，一次自动化。

这也意味着处理问题的方式不同。 通常，如果测试在测试环境中运行并且发现了错误，则会将其记录在错误跟踪系统中。 因为测试首先在开发环境中运行，所以开发人员可以遵循测试用例通过代码的路径。 这意味着如果出现问题，开发人员可以实时看到它并进行相应的调整。 这有点像测试驱动的设计 – 你有一个测试用例，你可以在进入下一个软件之前使软件正常工作。 我们唯一的偏离时间是修复时间超过30分钟，在这种情况下我们会将问题记录在错误跟踪系统中。

但最重要的是，这意味着开发人员和测试人员在测试执行期间紧密合作。 如果您在敏捷团队中工作，这是合乎逻辑的，但在实践中体验它是很好的。

左移的利弊

我们不想暗示左移一直是完美的，甚至总是适用的; 像软件开发中的其他方法一样，有许多优点和缺点。

第一个优点是测试人员和整个团队的开销更少，文书工作也更少。 这更像是左移的先决条件。 在一些项目和测试方法中，文档数量非常庞大，最终你会得到大量的文书工作，而这些文书工作可能永远都不会被重新审视。 在左移环境中工作时，我们仅记录必要的内容，例如无法快速解决的问题的错误报告。

我们经历的第二个优势是学科之间更好的合作。 由于测试人员早期开始进行测试准备，因此大多数测试条件是通过与设计该功能的分析师讨论而收集的。 通过参与设计活动，您可以熟悉功能以及开发人员计划如何实现它。 通过与开发人员一起进行测试，您可以讨论您所看到的内容以及开发人员如何解释要构建的功能。 开发人员和测试人员也可以讨论错误，与记录工具中的错误相比，这肯定更有效。

第三个优势是团队中的每个人都在思考并在他们的舒适区之外工作。 通常测试人员只关注规范来进行测试设计。 但是在左移的情况下，您与开发人员一起工作，因此您可以获得有关功能的相同信息。 这节省了大量时间来讨论系统的用途，并且您可以更好地了解其他开发规程正在做什么。 在进行测试设计和准备测试时，开发人员还可以帮助您，这使开发人员和测试人员能够更好地了解其他学科正在做什么。

我们看到的最后一个优势是左移可以实现早期自动化。 通过早期测试，团队创建了更早自动化测试用例并重用自动化测试用例的可能性，即使在sprint中也是如此。 最好在自动化之前执行测试用例，以确保测试用例在自动化时顺利运行。 通过先前执行它，您可以更早地自动执行它。

然而，左移也存在一些陷阱和缺点。 第一个缺点是测试不那么独立。 在测试期间与开发人员密切合作时，您可能会尝试实际测试开发人员已实现的代码 – 但这并不总是您应该测试的内容。 在这种情况下，测试人员应该测试的是规范所说的，而不是开发人员对此的解释。 运行集成测试可以缓解这个问题，但它仍然是测试人员应该注意的事情。

第二个缺点与指标有关。 他们不讲述整个故事。 这个缺点有点主观，主要取决于你对问题的处理方式。 在这个项目中，我们决定只记录开发人员无法直接修复的问题。 但是，该组织使用的关键性能指标之一是系统测试和集成测试中发现的错误数量与验收测试和生产期间发现的错误数量。 因为我们记录的bug很少，所以数量似乎很低。 管理层对如何实现这一点感到好奇，因为他们的指标与验收测试中发现的问题不符。 由于这种工作方式，该指标不再具有价值。

成为左移信徒

该项目的主要目标是满足新业务规则引擎实施的最后期限。 通过在另一个环境中提前开始测试，我们设法做到了。 但是，对我们成功的主要贡献在于，多学科团队中的每个成员都超越了自己的责任。 当团队习惯这种工作方式时，他们都喜欢它。 测试与其他学科之间的合作大大改善。

这个故事的一个有趣的细节是团队中没有人听说过之前的转变。 我们只是在寻找他们遇到的问题的实用解决方案，这是合乎逻辑的工作方式。 既然我们知道这是一种可靠的方法，我们可以说我们是左移的支持者。

个人理解

如果左移的方案中，只记录开发人员无法直接修复的bug。处于bug少了参考价值外，似乎也在“承认”开发人员可以不用“认真”自测自己的代码，为了避免此类情况，需要采取一定的措施。

开发与测试的重叠/并行，除了研发周期的缩短外(开发时间+测试时间)，也意味着集成测试可能成为上线前的把关关节了。