测试左移和右移

一般的测试流程：接到项目后参与需求评审，然后根据需求文档写写用例和准备脚本，等开发提测之后正式开始测试、提bug、回归，测试通过后就结束了，项目交给运维上线，之后投入下一个项目继续重复这样的流程。这样的流程看似没什么问题，但缺点是，测试同学非常被动：当需求质量、开发质量差的时候，你只能被动接受，结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期；同时很有可能一个线上问题裸奔了几个月，最后是业务方先发现才排查到是bug导致，由于影响时间过长给公司造成的损失巨大，还被质疑为什么这么明显简单的问题上线之后没人发现。
但是如果你实践了测试左移以及测试右移，你就能拥有更多的主动权，你有更充足的时间进行测试，同时不会像之前因为质量差风险高每次都延期上线，并且产品的质量也能有保证。为什么测试左移和右移能做到这点呢，我们先了解一下什么是测试左移和右移。
测试左移
测试左移就是在提测之前已经介入了测试。在需求评审时不只是了解需求，更是要去评估需求的质量，分析需求的合理性以及完整性。在开发阶段时也要参与设计方案的设计，了解开发的实现方式。因为很多开发可能只对他负责的那一块熟悉，作为测试需要评估改动范围以及是否有遗漏的模块和系统。测试还可以通过提供测试案例或者自动化测试脚本的方式给开发，让开发在设计时考虑地更全面，同时方便开发在coding时进行自测，有助于提高产品质量，毕竟越早发现问题，解决的成本就越低。测试同学还需要不断地培养产品、开发同学的质量意识，同时提供必要的技术支持，协助产品、开发更好的进行测试，比如公共用例、测试工具、测试脚本。这样，你会发现提测的质量大大提高了，原本提测后你还需要花一天的时间进行冒烟测试，现在都可以有时间进行更多的探索了。
测试右移
测试右移是上线后测试同学仍需要关注线上情况，不能认为功能上线测试同学就可以退出了。通过线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。在开发设计时就要考虑预警功能，系统层（如cpu、内存问题）、应用层（如响应时间）、业务层（如注册率、交易量）等出现异常的时候通过邮件等方式发出预警，相关同学才能知道哪里出了问题。技术同学要比业务方先发现问题，如果业务方已经发现业务量明显下降，说明问题已经很严重了。你也许会问，这跟测试同学有什么关系呢？测试同学可以监督开发需要补充监控预警功能，同时可以提供监控指标。还有一个是关注线上业务及用户使用情况，更多地关注用户价值高、使用率高的功能，在用例中补充遗漏的场景，尽量多地覆盖这些功能。
不管是测试左移还是测试右移，都是为产品质量服务。不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试同学需要关注的。