在敏捷的世界中，团队被要求更快地行动-缩短交付时间，同时仍继续提高每个版本的质量。同时，他们面临着降低测试成本的更大压力。
这种敏捷方法意味着具有不同技能的不同测试人员都将参与测试过程。更具体地说，这意味着开发人员比以往任何时候都更早地进入测试周期。
测试界的这种运动通常被称为“向左移动”。
向左移动意味着什么？
过去，大多数软件团队都使用瀑布模型进行工作，该工作流程类似于Winston Royce于1976年首次出版的“管理大型软件系统的开发”中的示例。
在此模型中，典型的项目可能如下所示：
产品人员消失了，去与客户交谈。最终，它们以规范，要求，路线图或一些用户案例出现。然后，举行简短的会议，开发人员讨论新功能，分配任务，然后每个人都下班。当测试人员混在一起时，通常是坐在计划会议中，或者可能估计他们测试新代码将需要多长时间。
即使是敏捷团队，大多数项目都觉得测试是过程的最后一步。我们很乐意让开发人员在产品开发过程中尽早与产品开发人员进行协作，并以较小的数量来构建产品，但是尽早进行测试是一个艰巨的任务。最后挤压测试会产生问题。最大的问题是，随着团队尝试更快地移动，测试变得有些瓶颈。上周不是测试周。这是一个发现问题，花时间研究和报告，获取新版本（有望成功）并每周重新测试。当人们忽略同时发生的所有其他事情时，测试只是瓶颈。在大多数公司中，这只是事情总是要做的方式。
建议不要在发布前的最后几天进行测试，这是解释“向左移动”一词中想法的最简单方法。在某些团队中，从一开始就涉及测试。测试人员参加设计会议，询问有关客户工作方式的问题，最终导致设计变更。一些团队成员可以与后端开发人员紧密合作，提出问题，创建测试想法和“假设”类型的场景。其他人则与API开发人员坐下来，并在开发新服务时对它们进行测试。然而，其他人发现他们与UI和API开发人员结对，以在机器上的新东西出现之前对其进行测试。
测试可能仍会在最后进行，但是由于您可以早点发现问题，因此测试会变得更小，更快。左移并不能使测试更接近发布周期的开始。它将其撒在每个步骤和每个迭代中。
“左移”是一个新主意吗？
在1950年代，程序员知道最好早开始进行测试，并做到了这一点。当时没有专门的测试人员。提问和测试是由编写代码的同一个人进行的，并且贯穿整个项目。不幸的是，对于瀑布模型的误解使我们失去了独立的测试团队，并且使今天的开发人员和测试人员之间的时间间隔有所延长。即使使测试发生在更早的想法并不是什么新鲜事，但是使用短语重新开始了一次重要的对话。
当我们将测试注入项目的所有部分时，工作的真正效果是什么？
测试工作往往需要大量等待。首先，人们在等待需求，然后等待具有新功能的新版本，然后等待开发“完成”，以便测试团队可以开始进行回归测试。很多时间要么闲置，要么试图找到避免闲置的方法。当测试开发人员在测试过程中较早加入时，情况将发生巨大变化。
作为集成团队的成员，测试人员的常规节奏看起来更像是开发人员的日子。他们可以开始与开发人员进行设计会议。即使某人可能不具备深厚的编程技能，并且从不熟悉产品代码库，但仍有地方可以增加测试性的价值。想象一个项目，该项目专注于构建向导以帮助构建广告活动。将数据分组到页面中，然后单击“下一步”按钮以转到向导中的下一步。下一步按钮确实很棘手。每个步骤都有必填字段，其他字段需要验证，并且可能会丢失数据。解决有关营销人员如何制作广告的一系列问题，可能会导致团队在软件甚至还没有存在之前就进行更好的设计。
如果有一个API，那么至少具有一点技术倾向的测试人员可以在开发周期的早期就编写一些基本的检查和测试想法。在美好的一天，可以在服务就绪后立即在构建中启动并运行服务测试。一些测试人员能够使用工具和几行代码执行大多数数据测试-数据长度，字符类型，数据格式-通常称为域测试。等到后端和服务层连接到用户界面并与最终产品有些相似时，剩下要做的就是寻找工作流程，布局和UI问题。
尽早进行团队测试可以帮助他们更熟悉工具和技术。理想情况下，软件以可测试的增量交付。但是，这些增量并不总是以Google Chrome浏览器中显示的形式出现。能够使用API工具，在服务器上查看处理的内容或在一些帮助下浏览代码已成为一项必备技能。没有这些，测试就被卡在了我们开始的地方。在最后。
管理者的日常生活也可以急剧变化。
当测试脱离开发范围时，人们会有一些奇怪的想法来管理测试。经理试图通过测量错误计数和一天运行的测试数量之类的指标来衡量测试人员的性能。开发团队开始以某种方式开始认为，用完文档测试就意味着我们越来越接近发行版。当团队帮助测试更早进行时，这些事情就消失了。
从空白页开始，编写生产代码和测试以与构建并行运行，或者一起快速测试和修复问题。希望在配对会议结束时，该功能即将完成。至少在那时足以为团队进行演示。到那时，需要管理者的过程中的某些部分（尤其是收集有关测试速度，分类错误以及获取功能状态的信息）消失了。当您可以完成工作时，谁需要错误报告和测试用例？对于传统的测试经理来说，这可能是一个挑战，因为他们花费大量的时间报告状态，找出被阻止的人并收集指标。向左移动测试，可能只是将测试管理移出或转移到新角色中。
很容易接受这样的想法，并告诉人们“您要做的就是分解团队结构，以小组形式重新创建他们，将一些人换成新角色，一次开始提供一项功能，然后保存”。事情很少那么简单，尤其是当有人告诉你他们是如此的时候。
