撰写之前在《敏捷测试的核心》、《构建测试的体系化思维（进阶篇）》和《一页纸测试策略》等文章中提到过测试左移，但是没有专门针对这个主题做过系统的介绍，但又总是被社区朋友问到。本文旨在介绍测试左移及其相关实践，希望能够解答朋友们的疑惑。
01 什么是测试左移？
传统软件开发生命周期一般分为如下五个阶段：需求分析、软件设计、程序编码、软件测试和上线发布。其中软件测试是软件编码完成之后的一个独立阶段，通常由测试人员来负责完成测试相关工作。如下图所示，从左到右依次为上述五个阶段：
测试左移就是针对传统独立测试阶段而言，将测试活动左移到图中测试阶段左边的多个环节，对每个环节所做工作进行测试验证，以确保其正确性，如下图所示：
- 需求分析环节的测试活动是为了保障需求的合理性，确保团队在做正确的事情；
- 设计环节的测试活动是为了保障设计的合理性，确保易于实现所期待的功能；
- 编码环节的测试活动是为了保障开发人员所写代码和所开发功能的正确性；
- 在测试环节还需要有相应的测试活动来对功能和非功能需求进行最后的验证和确认。
图中所示各个活动是从左到右按先后顺序排列的，因此测试左移也被称作测试前移。
注意：上图中的需求分析、软件设计、程序编码和软件测试等可能不再是非常独立的阶段，而是融合成为了整个开发阶段的一个环节而已。
02 为什么要测试左移？
有一条曲线，大家应该都不会陌生，那就是缺陷修复成本曲线：在软件开发生命周期中，越往后发现的缺陷，其修复成本就会越高，甚至到了后期会指数级增长。
而测试左移，主要就是为了获取快速反馈，以实现缺陷预防，降低成本。
1. 快速反馈
关于快速反馈，可以借助于玩游戏的体验来理解。在我们玩游戏的时候，每前进一步就能知道是成功了还是失败了。如果在软件开发中也能如此快速获取反馈，不仅能改善软件开发的体验，增加成就感；还能更及时发现偏离正确轨道的风险，尽早发现可能出现的问题。
因此，我们需要在测试阶段左边的每个环节去开展测试活动，实现测试左移。
2. 缺陷预防
如果能够全面统计一个软件产品的所有可能引起缺陷的地方，我们可以说该软件存在缺陷的总量是一定的。（当然，现实情况是我们不可能全面考虑到所有的因素，缺陷是很难穷尽的。）
如果这一定数量的缺陷中有一部分可以通过某些措施来预防，那么软件在测试或最终用户使用过程中所暴露出来的缺陷数量就会减少，这就是缺陷预防——减少暴露给用户的缺陷。
软件开发过程是个持续递增的过程，预防缺陷也不是一蹴而就的事情，需要在整个软件开发过程持续地进行。因此，需要持续频繁地开展测试左移相关测试活动，预防缺陷，实现质量内建。
03 测试左移实践有哪些？
所有在测试阶段之前开展的相关测试活动都可以认为是测试左移的实践，它们包括但不限于以下活动：
-
需求澄清：需求澄清需要团队多个角色协同参与，包括业务分析人员、测试人员（QA）、开发人员、技术负责人、技术架构师等。在《构建测试的体系化思维（基础篇）》中有关于QA在需求澄清环节所能做事情的详细介绍。
-
需求评审/用户故事评审（Story Review）：需要开发和测试跟业务分析人员一起讨论确认需求，可能是正式的会议针对某个特性（大块需求）的评审，也可以是针对单个需求条目或敏捷用户故事进行线下评审。如果前期需求澄清过程中对需求的讨论已经比较透彻，这里的评审就会比较轻量级，由测试人员（开发按需参与）自行安排时间评审即可。
-
行为驱动开发（BDD, Behavior Driven Development）：关于BDD，很多人误认为是一种测试方法，但其实BDD主要是为了三方更好地对需求达成一致认识，只不过通过BDD方式产生的需求能够很好地指导自动化测试的开展。更多详情，请参考我之前的文章《说起BDD，你会想到什么？》。
-
实例化需求（SbE, Specification by Example）：SbE的核心思想跟BDD类似，但强调了一点要将需求描述通过实例来说明，以更好地发现漏掉的需求，让需求更完整、更容易被多方理解和澄清。
-
QA/测试人员参与技术方案讨论：主要基于两个方面原因：一方面，测试基于自己对系统的了解，可以给技术方案的讨论提供输入，比如系统重点需要考虑和关注的问题等，以帮助验证技术方案的可行性；另一方面，QA清楚了解技术方案，才能更好地设计相应的测试策略，更完备的进行测试。
-
用户故事启动（Story kickoff）：在不同的语境下，也叫需求条目启动、开卡等。对于单个用户故事，在开发人员要开始编码前进行的再次澄清和确认，主要是确认其中的验收标准是否不够完备、是否大家都理解一致了。形式要求尽量轻量级，在开发人员电脑前完成即可，需要业务分析、开发和测试共同参与，时间一般不要超过15分钟。
-
用户故事桌面检查（Desk check/Shoulder check）：跟启动是配对的，也叫需求条目验收、结卡/验卡等。同样在开发机器前面完成，一般由开发将功能演示给业务分析和测试人员，大家确认需求中的正向路径是否都已经开发实现了。更多详情可参考文章《高效用户故事验收》。
-
测试驱动开发：TDD，常见的有单元测试驱动开发（UTDD）和验收测试驱动开发（ATDD），通过先写测试的方式驱动设计的完备性。Thoughtworks同事刘冉老师有多篇关于TDD的文章，请移步他的网站「刘冉的思辨悟」查阅参考。
-
代码评审：Code review，也叫代码回顾。有团队成员聚集在一起做回顾的，也有独立线下评审的模式。伍斌道长的文章《Code Review: 超越“审、查、评”的代码回顾》有关于code review非常详细的讲解，请移步参考。
-
编写单元测试和接口测试等自动化测试：根据测试分层理论，自动化测试可能包括单元测试、接口测试和端到端测试。通常单元测试是开发人员编写，而接口测试和端到端测试可以开发和测试协作完成。其中，通常建议单元测试和接口测试在用户故事开发环节完成，应该属于用户故事开发DoD的一部分。
-
测试评审：测试评审一般发生在Desk Check环节，主要针对开发所编写的单元测试和接口测试等。详情参考文章《QA评审底层测试的价值》。
-
持续集成：持续集成（CI）概念大家并不陌生，但是有效实施却不是那么容易。推荐参考Thoughtworks洞见文章《持续集成理论和实践的新进展》和《对于持续集成实践的常见问题的解答》。持续集成常见的反例有：
- 光有持续集成流水线，但是流水线上啥也没有，没有代码扫描、没有自动化测试、没有质量门禁；
- 流水线有接入代码扫描，但是扫描出问题没有及时修复；
- 自动化测试没有在流水线上频繁执行，或者执行失败不能及时修复；
- 代码没有频繁提交；
- ……
04 测试左移需要注意什么？
关于测试左移，业界同仁中存在一些认知误区，下面是我想强调的几点：
1. 测试左移不是QA或测试人员的左移，也不是简单移到需求分析阶段
测试左移常被误认为是QA或者测试人员参与需求分析。其实，测试左移不是人员的简单左移，而是将测试活动左移，在需求、开发等多个环节开展测试相关活动。只要是在原有独立测试阶段之前做的测试工作都可以算作测试左移。
可能大家也会注意到我们会强调QA/测试人员参与需求分析，或者说从需求分析阶段开始介入，其原因主要是因为在绝大多数团队，QA/测试人员还是作为质量保障工作的主力，左移的测试活动暂时还离不开这些主力的参与。
2. 测试左移不仅是开发自测/提前进行自动化测试，也不仅是TDD
说到测试左移，有人就会提到开发自测、TDD或者开发编写自动化测试。当然，这些都是测试左移实践，但测试左移实践远不止这些。
3. 测试左移跟持续测试分不开，需要持续在各个环节进行测试活动
测试左移相关测试活动都不是一次性的，而是需要持续频繁地在整个软件开发过程中开展，实现持续地测试，持续地获取快速反馈，实现缺陷的真正预防。
4. 测试左移实践不能流于形式化
任何实践都不能流于形式化，测试左移实践当然也是如此。对于任何一个左移实践，不能人云亦云，而是要根据实践所能带来的价值，结合自己项目团队的实际情况去开展。同时要不断回顾，进行调整和优化，让实践发挥真正的价值。
5. 测试左移实践需要跟测试右移/生产环境下的QA活动形成良性闭环
在《测试右移——生成环境下的QA》中介绍生产环境下的QA的时候，提到过需要跟前期各个活动形成良性环路：
生产环境下的QA所设置的监控标准是根据系统的行为特点和在预生产环境下的表现来定义的，生产环境下各项反馈的分析结果反过来又影响着预生产环境的QA过程，而且这两者是相辅相成的，只有形成了良性环路，才能把生产环境下的QA做好。
也可以理解为测试左移活动需要跟生产环境下的QA活动形成良性环路，比如：在Desk Check环节增加日志记录评审（Logging Review），确保日志记录是满足生产环境下的QA的；生成环境下的缺陷分析，反过来也可以帮助优化测试左移活动，更好地做到缺陷预防等。
6. 测试左移不会增加QA的工作量
说到测试左移，就会推荐QA/测试人员尽早介入，最好能提前到需求阶段，大家自然就会以为原本QA/测试人员就已经够忙了，再左移岂不是更忙不过来了？
其实，不必担心这个。
根据树莓酱定律，在测试工作量一定的情况下，全生命周期开展测试，是将测试工作分散到各个阶段，每个阶段的工作量会有所减轻。而且我们知道越早开展的测试工作，能够做到更快速地反馈，其有效性越高，价值越大。
因此，QA尽早介入，不会增加工作量，只是将测试工作的开展时间进行重新安排。
05 推荐阅读
《敏捷测试的核心》
《构建测试的体系化思维（进阶篇）》
《构建测试的体系化思维（基础篇）》
《一页纸测试策略》
《高效用户故事验收》
《QA评审底层测试的价值》
《测试右移——生成环境下的QA》
《测试右移：缺陷分析如何帮助质量内建？》
《测试右移：日志收集与监控》
《软件测试中的「树莓酱定律」》