一、开发提测时的提测质量同时受多个因素的影响
1、项目的规模。这里可以理解为,项目的规模越大,通常合作的人越多、需要考虑的逻辑越多/越复杂;项目的规模越小,相比之下,开发人员需要考虑的逻辑也比较容易把控。因而,规模较大的项目的提测质量,通常比小规模项目的提测质量要差一些。

2、开发同学的自身项目经验。日常的项目跟进中,对于类似的一些需求,通常经验丰富的开发同学的提测质量会好很多。
3、涉及业务的复杂程度。如果一个业务涉及的模块较多,关联的第三方业务较多,那么无疑这个业务修改时,出问题的概率也会越大。
4、开发周期的长短。开发周期通常需要技术团队来评估,但如果为了赶项目,而压缩开发周期时,通常会给提测质量留下隐患。
上面的因素会直接或间接影响提测质量,但由于这些因素属于客观因素,每个团队、项目都会有所不同,且不太受人为因素的影响,因而这些因素不是本文讨论的重点。那有哪些事情是可以提前做的,来确保提测质量呢?
二、确保提测质量该如何做?
确保提测质量的目标是在提测时,确保项目达到一定的质量水平。因而,抛开那些影响提测质量的客观因素外,我们需要做些事情,来确保提测时的质量水平,让提测质量尽可能逼近上线质量。
  1、明确项目流程。这里的项目流程,不仅仅是提测流程,也包括需求评审、测试用例评审、技术评审、风险分析等等,确保项目有任何实现风险、提测风险时,能快速周知到项目成员,方便大家一起齐心协力解决,而不是一个问题的block,直接阻塞的项目的顺利进行。
2、合理的需求评审。这里的需求评审的目标,是力求项目各个角色成员对需求的理解一致、对需求的风险点、影响范围等理解无歧义。避免技术实现与需求不符的情况发生。

详细的用例评审。这里的用例评审,是为了确保场景覆盖,以及再次确认项目各个角色成员对各个需求点理解一致
3、技术评审。QA同学与开发同学一起技术评审,可以提前预防/发现技术设计、技术实现方面的问题
4、静态代码扫描。确保代码的实现规范符合团队要求,保证代码的长期可维护性适时的人工Code Review。这里可以针对代码实现逻辑、规范做具体检查,提前发现问题,也可以使用工具,如sonar等。
5、明确的冒烟用例。冒烟用例是提测前,需要开发同学必须自测通过的用例。冒烟用例最好自动化进行验收,避免因为开发同学执行的问题,导致测试执行不彻底
6、公认的提测流水线。提测时,可以将静态代码扫描、自动化冒烟测试、自动化主流程回归测试进行集成,让开发同学提测前进行自检。
7、QA提前介入测试。QA提前测试本质上已经进行测试了,但由于尚未正式/全面进行测试阶段,因而一定程度上,也可以确保提测质量