“测试左移”带领测试走出处于最下游的困境
公众号关注：测试充电宝，一起交流
测试人员的烦恼，测试是处于研发流程末端，因此前期的各种问题都会影响到测试。如何打破这种困境，已经成为测试人员迫在眉睫的问题。
作为测试应该有责任去监督开发，产品等各个环节，以免对测试端造成影响。建立测试左移的思想，从需求阶段开始思考，如何对整个流程质量的保障。
所谓测试左移，就是控制上游质量，提前规避风险。如何做好测试左移，可以从下面几个方向切入：
需求阶段
需求的频繁变动，我想研发和测试都是非常苦恼的一件事情，而且维护成本也是非常大，如何提高需求的质量已经刻不容缓！
- 多提问题
在需求评审前，产品一般都会提前给出本次评审内容，这个阶段可以要求测试和开发提前对需求有个了解和思考，并且针对一些不确定或者存在问题的地方做好记录，待正式评审的时候跟产品经理一一确认，保证需求的质量和稳定。
- 合理的奖励制度
针对提出的需求问题的价值，可以进行分级，一旦被产品采纳，则可以给与对应人一定奖励，提高大家对此环节的积极性。共同来保障需求的质量。
- 设立需求反讲环节
可以安排测试或者研发来进行需求讲解，同样提升大家对需求的理解，当然这可能会导致里程碑的延后，可根据情况进行选择。
研发阶段
如果测试人员有能力，可以参与研发的设计评审和数据库评审，因为测试是对业务最熟悉的，如果存在业务上的设计缺陷，能提前规避。
用例阶段
- 列重点、画流程图
在需求拆解过程中，可以先把业务流程图画下来，然后用思维导图列出本次迭代的测试点。虽然会带来额外的工作量，但是我觉得短期可能工作量有，但是后期的收益也是可以预见的。
- 业务流程图有助于对需求和业务进行深入思考；
- 测试重点和业务流程图作为知识文档沉淀，有助于新入职员工快速融入团队，开展工作；
- 流程图和列重点更直观，后期评审用例也有提效作用；
- 组织内部互审
用例写完后，可以先组织测试人员内部互查，达到查缺补漏的效果。
- 用例评审
产研测三方评审，同样可以设计用例反讲，但是也是根据团队情况而定，评审过程中挑重点，非重要的可以一带而过，提高评审效率，会议越拖收益越低。
提测阶段
对于开发提测，我们可以设立提测准入条件。
- 选取本次迭代重要的测试用例给开发自测；
- 分发给开发的用例必须自测通过；
- 提测后，测试冒烟通过；
满足以上条件后，才能进入系统测试。
上线阶段
首先我们要设立上线的质量标准，比如：
- 不能带着严重bug上线；
- 测试用例必须全部通过；
- 一些轻微bug经过商议允许上线，必须在下一迭代作为高优先级进行处理；
- 做好上线方案；
结束语
以上都是我在工作中的一些总结，大家不必完全一直按照文章所列点去做，我们要根据项目实际情况做出调整，毕竟全部落实需要投入更大的资源，因此我们可以不断试错，找出收益最大化的一个平衡点。
希望本篇文章能给处于困境中的你带来一些参考价值。
