在前面文章“探索：测试的核心价值到底是什么？”里，简要提到了 测试左移 和 测试右移 ，这个概念相信大部分测试都了解。在我们的印象中，测试左移是为了尽早发现缺陷，降低修复成本；测试右移是为了及时发现线上问题，减少用户投诉。那么测试左移和测试右移的意义就仅仅是如此吗？今天就从这个话题开始，对传统的测试理念开启一次升级之旅。
1、测试左移在干什么
对于测试左移，比较一致的观点是：测试左移是为了尽早介入软件研发流程，避免等到测试阶段时才发现许多问题，导致整体修复成本过高，最终使得项目无法按时交付。所以在一定程度上，这代表着测试对自己将拿到一个什么样的半成品充满了焦虑，因此我们才迫不及待的想提前做点事情。
不是吗？我们是否在收到提测包时为主要流程都跑不通而感到愤愤不平？我们是否在发现研发实现与需求文档不一致时内心充满了无力？于是为了摆脱这些困扰，测试们削尖脑袋往“左边”挤，希望能把这些问题及早扼杀在摇篮里，以免接手到一堆烂摊子让自己疲于奔命。
由此可见，测试之所以需要左移，最关键的一点是，我们认为当软件到达测试环节时测试人员才开始干预，这实在是太晚了，晚到承受的风险超出了团队的控制力。于是我们通过测试驱动开发、单元测试、持续集成等一系列手段，把测试活动尽可能地做在前面（即左移），以此降低缺陷延迟发现带来的风险。
然而，这里面却潜藏着一个重要问题：测试左移的产生，本身就意味着测试人员对软件质量失去控制。先别着急，我们再来看看测试右移。
2、测试右移在干什么
对于测试右移，相对普遍的观点是：测试右移是为了持续监控软件的线上质量，以验证产品在用户的实际数据、环境、使用路径下，功能、性能以及产品体验，能够符合预期。略有夸张的说，这或许也代表着测试对自己检验过的成果并不那么自信，所以我们希望听听发布后的声音，直到确认它已经在稳定运行，才能稍微松一口气。
我们是否有过这样的经历：当你费尽心思，把自己能够想到的用例做了 N 轮反复验证，并满怀期待地发布之后，现实依然能从某个不可思议的角度，给你狠狠的敲上一棍子。更为苦恼的是，事后无人关心你前期测试的多么辛苦，只会问你：测试的时候没覆盖到吗？所以测试们只能往生产环境里塞进更多监控，祈祷能够赶在用户投诉、老板发飙之前，自己把问题悄悄处理掉。
由此可见，测试之所以需要右移，最主要的动机是，我们意识到不论前期的测试做得多么完整，依然无法确信软件的最终交付质量能够达到团队的预期。于是我们只好通过埋点、监控、反馈收集等多种方式，让测试活动在生产环境一直延续下去（即右移），以此尽量减轻缺陷遗漏带来的影响。
但是，这里面也一样暗藏玄机：测试右移的产生，同样意味着测试人员无法保证软件的交付质量。而我们即便有了测试左移和测试右移，就真的能够解决质量问题？
3、做测试还是做质量
必须承认的是，测试左移和测试右移理念的提出，对于测试角色而言，的确是一个相当重要的进步，也能够解决部分问题。但无论是测试左移还是测试右移，都反映出一个残酷的现实：测试对质量的影响实在太有限，即解决不了“入”的质量，也解决不了“出”的质量。因此我们才不得不在整个流程中“上下求索”，以期获得一些安全感。
然而这样就可以了吗？虽然我们在缺陷的前期和后期都做了更多的事情，却依然改变不了这些缺陷存在的事实，也改变不了底层的根本质量。至多只是在这些不可改变的结果之上，做出些许努力，以此证明自己真的“尽力了”。而质量问题仍旧是个浮在水上的瓢，按下这头，起了那头。
因此，如果我们期望做到真正的高质量交付，终究还是需要回归到质量的本质：质量是被设计出来的，而不是被测试出来的。左移和右移做的再多，也解决不了设计带来的天生缺陷。我们要做的其实不（只）是测试，而是质量，而测试仅仅是质量中（甚至都称不上是最重要）的一环。
完整的质量设计，即包括质量体系的建设、质量策略的执行（测试活动是质量策略的一种），也包括质量问题的识别和质量过程的改进。它从始至终贯穿着整个产品的生命周期，从源头上即对质量做出了有效管理，最终确保高质量的软件交付。而做为测试角色，我们也应该及时调整自己的定位，我们不再是“测试”的执行者，而是“质量”的设计者。
事实上，包括作者所在的大厂在内，越来越多的人已经意识到了这个问题，纷纷将“测试团队”升级为“质量保障团队”。相信在不远的将来，这些理念也必然能够为大众所接受，成为行业的主流。
文章源自公众号 测试开发修炼之道