测试左移和测试右移

前几天看爬文的时候看到了这篇《Shift left and shift right: the testing Swing》，里面描述了一些测试左移和测试右移的思路和方法，觉得有一定的启发，可以分享一下。

作者站在项目或者产研发负责人的角度阐述了自己团队在敏捷及devops中的测试实践，根据功能和产品所处的生命周期，描述了这样一些开发及测试实践

• 开发阶段

• 新功能： 我们应该做什么？

• 已有功能：如何自动化？

• 产品阶段

• 新功能：如何验证新功能所带来的用户价值

• 已有功能：性能及可用性监控

测试左移

其中在开发新功能时候我们需要不断的问自己，我们实现的功能是什么？对需求做详尽的分析。作者认为bdd是一个很好的实践，用户或者客户去描述产品的行为，这种描述是有一定的规则或语法的，可以直接作为测试用例的描述，通过这些描述实现自动化的测试用例，那么我们的功能实现代码只需要通过这些测试用例就可以满足用户的需求了。

这是测试左移的思想，本质是在一切开始之前先进行测试，测试对象是需求，越早的发现需求不合理的地方出问题的几率就越低。

另外测试左移还可以是在开发阶段就进行测试，开发阶段可能产出只是代码，而不是完成的功能，这时候比较合适的测试是做持续集成的单元测试，通过代码覆盖率的方式找到未经测试的代码，尽可能的保证代码都被测试到。这些单元测试的用例可以在bdd时候通过用户或客户的用例描述来提炼。

总之左移是在测试阶段到来之前，尽可能的抓紧开发前(需求分析)和开发中的时间做测试，提前发现问题，防微杜渐，避免积重难返。

测试右移

左移是往测试之前的开发阶段移，右移是往发布之后移。也就是产品上线了之后也可以进行一些测试活动。当然在生产环境直接做测试是不推荐的，但是我们可以在生产环境做监控，监控线上性能和可用率，一旦线上发生任何问题，尽快反应，提前反应，给用户良好的体验。

测试右移其实还可以理解为如果线上发生任何问题，我们有没有能力第一时间发现问题并解决问题，并保证线上数据的一致性或尽可能少的影响线上用户。

很对时候，右移比左移更具有挑战性。

我们可以做什么

这里y有一些测试实践，是在不同的阶段可以去做的

• 开发阶段

• 新功能： 单元测试, BDD, 探索性测试

• 已有功能：自动化验证，性能测试，

• 产品阶段

• 新功能：可用性测试

• 已有功能：实时性能监控及用户反馈收集

其实我们不妨眼光放的更长远一点，软件测试实际上是软件质量控制，质量控制有很多实践，一些实践适合测试人员去做，另一些则可能不适合，比如线上性能监控，比如单元测试等。所以质量不只是测试团队的事情，而是整个项目或者产品团队需要重视的问题。一般来说，注重质量的团队产品或者交付质量往往好于不太重视质量的团队，或者把质量的指标压在测试人员头上的团队。

质量无小事，质量也不是某几个人的事。好的质量是团队的荣耀，不好的质量也不应该是某几个测试人员的锅。

最后，从质量管理的角度上看，好的质量管理者可能需要具备下面的一些素质

• 把质量问题上升为整个研发团队或产品团队责任的能力
• 能推动各种角色进行高效合理的测试实践的能力