说起测试左移，得从瀑布模型开始。
软件工程瀑布模型（waterfall model）概念，起源于 Winston Royce 发表于 1970 年的著名文章 "Managing the Developmentof Large Software Systems" (Proc. Westcon, IEEE CS Press, 1970, pp.328-339)。
虽然这个模型可能是个误会，可以见 Craig Larman 和 Victor Basili 教授在 2003 年发表于 IEEE Computer 杂志的封面文章 [《Iterative and Incremental Development: A Brief History》]( https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf) 中为我们讲解了一段非常精彩的有关瀑布模型的历史故事，这也可以说是世界软件工程史最大的误解之一。
他其实一直倡导的是迭代、递增和演进式开发，他在那篇文章中描述的瀑布模型其实只是一种最简单的情况，并不是普遍适用的，现在看也不是一种先进、最佳的方案。
瀑布模型的生命周期，包括需求分析阶段、设计阶段、实现阶段和测试阶段等等，其中测试又可以分为单元测试、功能测试、系统集成测试等。
测试左移是在瀑布模型的基础上，为弥补瀑布模型的不足，不让测试工作只成为产品交付前的最后一道屏障，而将测试往前提，将测试贯穿于整个软件研发生命周期中。
这里为什么是左移呢，是因为我们大多数的阅读习惯是从左到右，左在前。当把整个传统软件生命周期在一条直线上辅平，从左到右分为是从需求分析阶段、设计阶段、实现阶段到测试阶段，所以当我们想把测试提前的时候，在这条直线上，就是往左移了。
测试左移一词（shift-left testing）最早可能出现在 Arthur Hicken 的博客里，在他的博客中提到了对测试左移的看法。见这里：The Shift-Left Approach to Software Testing
其依据的核心逻辑是随着软件进入生命周期的后段，发现一个问题并解决的成本会急剧的增加，如下图所示：
成本增加的原因可能有如下几种：
- 关联方多：越后期，关联的模块越多，定位一个问题，解决一个问题需要联动的各方更多，成本显著增加；
- 影响面大：后期影响范围更大，修复一个问题需要考虑的问题更多；
- 流程拉长：当到测试甚至线上再出现问题，整个处理问题的流程拉长，从开发阶段的开发自我闭环，到测试阶段，测试和开发互动，到线上用户、客服、测试、产品和开发都要介入，其流程长度完全不一样。
从图上看，当左移后这些成本会显著减少。不仅仅是减少成本，还可以减少当出现质量问题时，归责于测试团队的问题，以及关于质量的责任问题的扯皮过程。在我们传统的研发过程中，测试同学处于一个被动接受需求，被动接收开发完的功能进行测试，能主动改变的事情不多，而往往背锅的时候都会有测试团队。
测试左移的核心逻辑或原则个人认为有以下三点：
- 开发同学是质量的第一负责人，测试同学是共同责任人并辅助开发同学做好质量工作；
- 预防 BUG 比发现 BUG 更重要，工作的重心是预防而非发现；
- 测试同学以一个相对外部的视角来提供质量建议以辅助开发同学做好异常处理，以提升开发同学的开发质量和技术能力，从而提升整体研发的效能。
在测试左移的研发流程中，测试同学有以下职责：
- 测试同学主动参与整个研发过程，从产品阶段的质量需求，到设计阶段的方案设计（测试人员往往对全局更加了解）等；
- 测试同学通过手工或者自动化的方式，对 prod、stage、fat 等环境的应用进行频繁的测试，而不用困在流程中等提测后再进行，更主动进行测试；
- 在流程中负责主流程的质量验证；
- 测试同学负责线上问题的跟进和闭环；
我们理想中把这种模式严格落地后，线上质量会提升并且开发同学的能力会有极大的增强。
这里可能会有同学提出关于人力成本的考虑，觉得把测试工作转嫁到了开发同学，或者觉得测试同学的思维模式是找问题，开发同学潜意识不愿意找，不愿意把自己写出的东西弄崩溃，认为需要有一个测试环节等等问题。
但是当开发是质量的第一责任人，并作为一个独立的主体，对自己开发的代码负责，对自己负责的应用负责时，会想办法来预防 BUG，提升质量，那些思维模式的问题会随之改变。
在我的职业生涯中也经历了几年自己开发，自己测试，自己发布的时光，感觉很爽，就是一点，特别谨慎（害怕），因为此时你会是一个独立的主体来解决问题，你得为你自己的代码质量买单，此时会想尽一切办法不出 BUG，预防 BUG，包括极度严谨的多次的 Code Review，每次都要走的多级灰度部署，验证，日志查看，留守。其导致的结果是在一个超过十亿 PV 的应用（中间还有大版本升级、基础环境的升级等大范围的操作）上两年没有出现过大的事故（当然有灰度过程中的问题，但是及时发现并解决）。
那么，作为一个技术团队管理者在开始践行测试左移时需要考虑什么？
- 团队是否适合做测试左移，测试左移对于开发同学的要求会比较高？
- 是一把梭，还是先试点，需要评估一下这个改动的影响范围，考虑灰度一下？
- 业务需要快还是慢，对于慢业务用传统的瀑布是否更合适一些？
- 左移到什么程度？
回到主题，测试左移到底移了什么？
我的理解，测试左移，移的是角色职责，移的是责任主体，移的是质量意识，这些不移，其它移了都会是事倍功半。
