提测前做的、和质量保障相关的事情，个人理解都是左移。左移是相对于传统的测试主要在测试阶段才开始介入而提的概念。

比如需求评审时能提出更多提高需求质量的意见并推进让产品采纳；技术方案评审时能及时提出一些方案存在的风险缺陷（比如和第三方交互是否有充分可靠的补偿重试机制）并进行修正；代码提交时能通过一些自动检测工具自动发现那些低级的空指针错误；开发提测时可以通过 code review 来了解整体实现细节以及评估是否有风险（比如同时更新两个表有没有用事务避免脏数据等）等等。包括 TDD 、ATDD 这类测试驱动开发的方式个人理解也算是测试左移（比正常测试阶段提前了很多开始进行测试）

每次 build 就触发自动化测试这个是持续集成的概念，目的是及早集成和测试，确认每次提交代码后，软件达到最低限度的质量要求（能编译通过、最基本的测试可以通过）。也算是左移的一部分（正常迭代软件，在建立新分支的时候就开始做持续集成了）

左移其实挺难的，主要相关实践基本都离不开技术实践，对人员要求比较高。团队内有这样能力的人不多的话，安排做测试提效工具可能产出比弄左移要明显不少（而且一般开发水平不是太差的话，前期阶段能发现明显缺陷的概率并不高）。个人建议与其研究这些概念性的东西，还不如去审视下自己现在业务还存在什么问题，有什么合适东西可以去实践解决问题。现在已经是一个精细化的年代，很多实践并不见得都适合自己，按自己需要选择即可。