·测试是在开发提测后才开始，也就是说，测试人员必须等待产品完全构建才能找到故障。这通常会导致项目剩余的时间不足以保证完全测试所需的时间；
·当需求质量、开发质量比较差的时候，测试人员将经历一段痛苦的测试过程，甚至因为质量差而导致产品上线延期；
·后期Bug的每一次出现，都需要花费大量的时间和精力去修复；
·客户发现问题，排查到是产品bug导致，影响公司的形象。
测试是为产品质量服务的，我们不能把提测认为是测试活动的开始，把上线当做测试活动的结束。
这时候，我们不得不提及现在流行的测试左移了，测试左移的出现是为了进一步提高产品质量，在产品生命周期里更早执行测试任务（也就是在项目时间线上向左移动）。测试左移的思想本质是越早发现不合理的地方，出问题的几率就越低。
测试团队在软件开发周期的早期参与其中，这将帮助测试团队清晰的理解需求以及设计测试用例，让软件快速暴露问题，促使团队更早的修改BUG。参与和理解会使测试人员获取产品完整的知识，有利于测试人员构思使用场景，从而根据软件行为设计实时场景，帮助开发团队在编码完成前识别一些缺陷。
测试左移通过一系列的活动，提高质量的上限，缩短测试的周期，提高质量的下限。
那么测试左移该怎么做呢
在团队的Devops开发下，对于测试左移进行的操作：
·编写单元测试，通过单元测试提前进行测试；
·Code Review，通过代码走读发现一些基础的问题；
·参与需求评审，提出需求不清晰、不合理、遗漏等意见，了解开发的实现方式；
·参与研发需求分解，协助梳理分解遗漏点；
·参与概要、接口设计评审，协助梳理遗漏逻辑；
·提早输出测试导图，开发编码前进行评审；
·部分功能提测，提早开始测试；
·自动化测试，用于回归确保旧版本功能正确性；
测试左移策略在Capers Jones的一些著名图表中得到了很好的说明，该图表显示了在软件开发的每个阶段，引入到软件中的错误/缺陷的成本不断增加。图表的第一部分显示了预计大多数错误会在编码阶段进入。
无论他们是犯了实际的错误，还是误解了需求，还是不考虑特定代码的后果，开发人员都会在代码生成时引入缺陷。
当需要将各个部分组合在一起时，缺陷也会引入到应用程序中，尤其是在涉及多个团队的情况下（以及随着微服务等现代体系结构变得更加复杂）。
何时发现这些错误？
如上图，因为通常在开始测试时会发现错误，并且如果没有适当的基础架构就很难在一切准备就绪之前就开始进行测试。我们在这里看到的是，大多数错误是在编码期间引入的，但在该阶段几乎没有发现。
各阶段修复bug成本
由于大多数错误是在编码期间引入的，但直到下一个阶段才被发现，因此了解在开发的每个阶段修复缺陷所花费的差异就变得很重要。如下所示：
如上图，越往后发现缺陷，成本就会急剧增加。让错误潜入系统测试的成本是在编码过程中发现该错误的成本的40倍，或比在单元测试期间发现该错误的成本高10倍。
成本上升的原因包括：
跟踪问题所需的时间和精力。测试用例越复杂（越大），则更难定位具体问题的所在
由于引入了诸如数据库或第三方API之类的相关系统，沟通成本较大。（在这种情况下，组织在缺陷检测和缺陷修复之间通常要经历数周的延迟，这是很常见的。）
修复缺陷所需的更改的影响。如果这是一个简单的错误，那就没关系了。但是，如果在很多地方都做过，或者使用了错误的框架，或者所构建的代码的可伸缩性不足以承受预期的负载，或者无法确保安全性……
尽早测试、频繁测试（测试左移）
现在，观看下图中添加的橙色线，它说明了基于较早测试（左移）的缺陷检测周期：
可以看到橙色检测曲线在越早发现，修复成本越低，这大大降低了我们的成本。
左移依赖于更成熟的开发实践，例如基于软件测试金字塔的开发实践（开发人员创建了一组可以很好地覆盖代码的单元测试，而功能测试人员和API测试人员则尽其所能并最小化依靠后期测试，因此您只有足够的手动/ UI测试来证明一切正常。这样，后期测试就可以证明其功能，而不是发现错误。尽早测试，频繁测试是左移的口头禅。
测试左移
当进一步向左推动编码本身时，将获得更多价值。毕竟，这是引入错误的地方-因此，让我们在开发仍在进行的同时开始介入测试。这是我们从静态代码分析中受益的地方-通过查找最左端的缺陷来修复缺陷，其中修复成本最低的缺陷是：
通过静态分析，可以在实际的编码阶段开始寻找错误，这时发现错误的成本会尽可能地降低。
如上图，在“测试”开始之前先找到缺陷是最划算的。它也是最省时的，因为它不会给开发人员带来尝试重现错误或理解故障的任何问题。能够将缺陷修复周期从数天或数周缩短到数小时或数分钟，这是非常有用的。
测试左移不是增加开发工作量
测试左移偶然地给软件开发人员带来了过多的测试负担。查看图表时要记住的重要一点是，尽管随着正确的选择缺陷修复的成本急剧增加，但是左侧的资源可能是软件生命周期中成本最高的–这可能是使他开发人员不再专注于开发功能。
更早的发现问题是一方面，更重要的减少问题的数量，提升研发工程质量意识。
