前言

传统的瀑布式软件研发流程，测试环节通常处于SDLC的后期，测试人员承担着“质量守门员”的职责。而随着敏捷研发和DevOps等研发模式的推行，快速迭代、持续交付成为常态，相应地，“测试左移”这个概念也被高频地提及，很多实施敏捷的团队都将“测试左移”作为重要实践。

很多团队都会鼓励测试人员尽早参与项目，在需求、设计、开发环节都会让测试人员参与，包括需求评审、设计讨论、开发阶段的结对、单元/集成测试、持续集成管道、自动化测试等等，都有测试人员参与的身影。

本文，我们不讨论测试左移中这些具体的实践，而是想澄清一点：“测试左移”，并不仅仅是测试人员向前端的平移

软件质量

何谓软件质量? IEEE.1061的定义如下：

软件质量是软件产品满足规定的需求，以及基于用户需求和期望的隐含需求的程度。

这个定义很抽象，也从侧面说明，质量其实是一个较难明确界定的产品要素。

不同视角的角色看待质量其实是不同的。

用户视角

质量是满足用户需求和期望的程度。也就是产品是否能帮用户解决具体问题？是否方便快捷？稳定可靠？性价比高？

“这个软件很好用！” “这个系统稳定性好，从不崩溃！” “这个App用得很丝滑~”

开发视角

站在开发者视角，质量则体现在代码和架构上。

“代码是否规范，可读性，可维护性良好” “架构清晰，方便扩展” “技术债务可控”

测试视角

从测试者的视角来看，除了带入用户视角的体验外，质量更多是多种场景的适应性。

happy path、angry path、scary path、greedy path等等各种场景下，软件适用程度。

管理视角

而从管理视角来看，质量又体现在是否能按时交付？预算是否可控？产品指标是否满足？

“产品按时高质量交付” “研发成本大幅缩减” “系统稳定运行，可用性达到99.999%”

业务视角

而站在业务运营角度，质量衡量的是产品创造价值和竞争优势的程度。

“用户下载量”，“用户注册数”，“订单转化率”，“用户留存率”等等….

一千个人眼中有一千个哈姆雷特, 质量也如是！

说到底，其实还是落到我们经常强调的：质量不是由测试保证的，测试也无法保证！质量是和整个团队，软件生命周期链条上所有人都紧密相关的，人人都应该是owner！

测试左移的本质

通过上一节的说明，其实本文题眼所说，“测试左移”并不仅仅是测试人员的前移！ 就很容易理解了。

因为快速迭代和持续交付的推行，这一应运而生的质量控制举措，将测试人员前移，虽然测试相关活动已经不局限于后期验证，但如果还是把质量依赖于测试人员的相关活动，那么依然是治标不治本。

测试左移，本质上是面向全员质量文化的普及。测试人员的左移，更多是应该将测试人特有的，对质量风险敏感的测试思维带到前端，带动团队整体建立起质量优先的文化氛围。

亦即测试应该向【QA】转型！ 而且，这里的 QA, 并不是传统意义上，重在流程管控、做质量保障工作的Quality Assurance， 应该是适应敏捷模式的新型QA

测试向QA的转型

Quality Assurance

传统的QA岗位，即Quality Assurance(质量保证)，是一个专门面向质量体系的岗位，和测试岗位并不相同。QA的工作更多是质量标准的制定和监督，面向的全生命周期的流程管控；而测试更多是一个基于测试技术的工程岗位。

在测试左移的趋势下，测试就不再应该局限于测试技术的应用，而应该将视角转向Quality Assurance，也需要关注软件研发全链路中，各个环节的质量风险。

Quality Analyzer

这其实还不够！测试左移，并不是角色的切换，更重要的还包括测试思维的导入。也就是这时，测试还应该是Quality Analyzer（质量分析师）。 比如

在需求评审时：

寻找模糊地带：主动识别需求中的歧义点。例如，“系统响应要快”——多快才算快？“友好的用户界面”——如何定义友好？

提出"What if"问题：探索各种场景，包括正常流程、异常流程和边界情况：

• “如果用户在这里输入特殊字符会怎样？”
• “如果网络突然中断，数据会如何处理？”
• “如果用户没有权限，应该看到什么提示？”

确保需求的可测试性：评估每个需求点是否可以通过具体的操作和预期结果来验证

在架构/设计阶段：

从用户视角出发：检查设计稿的流程是否顺畅、直观

关注边缘案例：加载状态、错误提示、空状态页面等是否都已设计

评估可访问性：考虑设计是否对所有用户群体都友好

评估系统可测试性：确保系统是可验证的。包括日志的记录、操作流的追溯、第三方的模拟等等

评估非功能性需求及测试策略：确保系统架构和设计阶段已经充分考虑了性能、安全、可靠性等非功能性需求，构建相应的测试方案

在开发过程中：

推动单元测试覆盖：协助开发团队构建单元测试框架、提升测试覆盖

深入系统集成：和开发团队基于合适的分支管理模式，建立持续集成CI管道，构建自动化测试的质量门禁

通过深度参与前端环节，将测试思维和对软件质量的思考和敏锐观察，融入到测试之外的软件研发活动中。

Quality Advocator

此外，质量文化不是一蹴而就的，在一个高速运转的团队中，一个以质量为第一优先的角色，不断向团队倡导质量意识，在质量失控风险时能及时提出"异议", 更是“测试左移”后，测试人员的重要职能。

但这个新职能要发挥作用，离不开团队和管理层对质量优先的一致认可，包括对测试人员在左移后 相关工作的制度支持。否则，质量优先多半只会流于形式，不过一句响亮的口号

总结

随着敏捷、DevOps技术的不断发展，软件研发的速度、节奏和复杂性都在不断提升。在这样的背景下，测试左移要落到实处，质量文化的建立其实是根本。

而在这个过程中，测试也需要完成角色的蜕变，向质量顾问、质量分析师、质量倡导者转型，在更广大的范围发挥价值。

总而言之，推行“测试左移”，需要将质量思考融入进研发的每个环节，将质量文化烙入团队的DNA，最终构建出一个全员参与、持续改进的质量生态。