测试左移右移，到底是什么？
今年写了很多质量保障相关的文章，也做了很多相关内容的分享。关于质量内建和测试左移、测试右移的话题，多次提到过。有同学留言问：测试左移右移，在工作中到底该如何实践？
这篇文章，结合自己的工作实践和思考，来聊聊我对于测试左移和测试右移的看法。
质量保障的定义和定位
从软件产品的迭代闭环模型来说，质量保障工作应该是贯穿整个软件生命周期的。如上图所示，在不同阶段的具体工作，大概有如下几点：
- 计划：评估可行性、成本预算和资源投入；
- 需求：需求评审、需求分析、资源和任务分配；
- 设计：UI评审、技术方案评审、测试方案评审；
- 实现：单元测试、测试用例评审、code review；
- 测试：冒烟、执行case、追踪bug、问题修复验证；
- 交付：配置测试、灰度&验收测试、线上核心场景验证；
- 反馈&评估：线上质量巡检，稳定性保障，应急响应，质量度量；
从软件工程的阶段划分以及实际工作内容来说，测试同学的大部分时间精力只集中在测试阶段，如下图所示：
影响产品质量的因素很多：需求质量、设计质量、编码质量、甚至发布时的配置，都会影响最终的交付质量。
在和很多测试同学交流后我发现，大部分同学的日常工作主要集中在上图红色加粗字体部分，即主要做的工作是针对性的测试验证。这就和质量保障工作的定义有了冲突。
这也是很多时候，线上出了问题测试背锅的原因之一。测试的岗位职责是要保障最终交付质量，至少是核心责任人，但为了保障质量所开展的具体工作却没有覆盖到可能影响质量的环节里。
虽然质量问题不仅仅是测试这个岗位的单一责任，但是在找外部的客观因素之前，也需要反思自己的工作做的是否到位。
测试左移和右移的意义
聊完了质量保障工作的定义和在实际工作中的定位，接下来开始正题，测试左移和测试右移。
在这之前先对测试左移和测试右移有个简单清晰的前置定义：为了保障最终的产品交付质量和线上运行质量，应该将测试工作的开展范围，从测试验证环节，扩展到更大范围。
测试左移：将测试工作开始的环节从测试阶段向前移动，即覆盖到项目计划、需求、设计和开发阶段。
测试右移：将测试工作结束的环节从运维阶段向后拓展，即覆盖到服务发布、线上巡检，进行持续质量运营和度量评估。
为什么要开展测试左移和测试右移？因为影响质量的因素是多样的，且贯穿在软件产品的全生命周期中。
为了做好质量保障工作，控制风险，提高交付质量和用户体验，因此需要将保障的范围覆盖到软件产品的全生命周期中，利用各种方法和工具，从多个维度和环节进行测试验证。
测试左移和测试右移的价值是什么？从测试工程师这个岗位来说，左移右移可以提高质量，降低线上出故障的概率和可能带来的影响，提升测试团队的影响力和价值。从个人角度来说，即使出了问题，也可以更好的甩锅。
如何实践测试左移右移
关于测试左移和测试右移在工作中的实践，在前面的文章中其实聊过很多了。比如：
- 测试左移：加强需求和设计阶段的评审和风险评估，准备应对风险的冗余方案；需求实例化；单元测试；质量门禁；code review&code diff等；
- 测试右移：自动化测试、配置变更检查、灰度发布和测试验证、线上巡检、应急响应、质量度量和评估。
其实无论是测试左移还是测试右移，都可以看做是质量内建的一部分。当然做这些事情，离不开团队的协调沟通和工具方法的支撑。
在具体的实践里，可以根据团队自身的情况，选择合适的切入点去落地，先从较为简单且比较痛的点开始，快速拿到一个好的结果，才有利于争取更多的资源支持，扩大测试左移和测试右移的范围。
