前段时间与某互联网大厂质量负责人针对测试左移和测试右移进行了探讨，以下系列文章为整理其口述内容。测试左移和单纯的把测试减少有哪些区别？要理解测试左移，首先我们要一起聊一下，哪些行为属于测试左移？我们总结了测试左移的几个比较重要的行为：评审、技术对齐、自测赋能和多角色协作。接下来讲一下多角色协作。

最基础的一个软件团队，他的三个角色是产品经理、研发、测试，有可能会带运维、技术支持这样的岗位。多角色协作一般会用到两个平台，一个是需求管理平台，或者说是缺陷管理平台，需求和缺陷一般来说是管理在同一个平台上。另一个是自动化流水线平台，这个是偏技术项的一个平台。在使用这些平台的过程中，要求各个角色之间话术的对齐。

这个话术的对齐指的是，比如说我作为产品经理，我说的一个东西，跟一个研发你说的东西到底怎样是一致的？

对产品经理来说是一个需求，对于研发来说可能是一个新功能的代码分支。这个新功能的代码分支进行提测之后，对于测试是一个新功能的测试，他其实是需要在新功能的测试环境上去做测试的。如果说这是一个可稳定发布的版本，也就是说刚才说的新功能做完了，这个新功能已经合并到主分支了。对于研发来说，就变成了发布代码分支，对于测试来说就变成了回归测试。这些话术要对齐，对齐了之后，才能在平台上进行多步骤的拆分，进行流转。

多个角色之间是可以相互帮助来解决问题的，大家的关系不需要闹得那么僵，可以相互帮助来解决问题。比如说研发可以通过暴漏一些后门来提供高可测性，有些功能很难测，也很难测到，测试没有办法进行操作，对于测试来说这叫做“没有可测性”。那么研发可以开一个后门，比如说开一个接口，开了这个后门之后，测试就可以得到原本没有办法测到的一些信息，可以校验更多的东西。

第二个是产品经理可以通过一些提示文案，来避免误操作，规避易用性问题。这个相对来说比较常见，比如说，我们经常可以看到一个版本升级了之后，如果一些功能改变了，或者说一些按钮的位置变化了，产品经理可以做一些小提示，让用户能够看到。用户看到这样的小提示之后，他就不会去认为这是一个应用性的问题。

第三个是说，测试可以将内场的测试脚本放到外场去做，在线下写的测试脚本如果写得够通用，或者说屏蔽了数据的干扰，那也可以把测试本身放到线上去跑，来给我们的交付和运维来使用。所以说多角色之间是可以来相互帮助来解决这些问题的。