有同学提问：产品没有专职的测试人员，要怎么才能快速完成测试？
先说结论，这个问题并没有标准答案
没有测试岗位只是没有专门负责这个职能的人员，但测试这个事并没有消失
快速完成测试，其实应该换种说法，就是快速建立质量信心。
因为测试无穷尽，所以没有绝对的完成测试，按历史经验或大家达成基本共识，产品应该没啥问题了，就算完成测试。
那既然我们现在希望做的就是快速建立这个质量信心，或者说能快速跟相关干系人达成质量OK的共识，基于这个思路，要考虑哪些因素呢？
待测范围
要快速做完测试，一个途径就是测试范围少，比如改动很小，而且没啥关联影响模块，快速检验一下就可以了。道理跟开发代码及时提交、高频集成是一样的，不要积累变更，节省出问题后倒查一堆变更的时间。
开发阶段充分自测，并及时集成测试，不要积累变更。
已有质量
另一个方面是是否对产品现有质量有信心，开发是增量的，之前的存量是否质量是过关的？新增部分和存量部分的关联、影响是否都是已知的？产品质量是全量的，历史功能或影响同样对影响当前的质量信心，所以是否清晰新增和存量的关系，存量本身的质量是否过关也是关键。
潜在问题
再有就是，测试是黑盒的，并不能清晰知道冰山之下有多大的危险。但质量信心这个东西其实跟潜在问题并没有直接关系，它主要跟已知问题和已测范围相关，也就是已知问题越少、已测范围越大则信心越足。背后的逻辑就是，已知问题越多，往往意味着潜在问题越多，发现一只蟑螂，可能代表有一窝蟑螂。所以还是强调提测质量！自测没充分，就先别集成测试了，每个开发先把自己的一亩三分地扫干净先。
问题暴露风险
最后，还有一道防火墙，就是出问题的风险。问题暴露，炸了！ 但炸的影响其实不同，是冒个火星就灭了，还是炸个洞，甚至整栋楼塌了！除了问题本身的大小，不同产品对问题的接受程度其实也不一样，在一个等着拆迁的大楼里放个炮仗，大不了也就是提前拆迁了，容忍度高，信心就足！
总结
综合以上几个方面，快速完成测试，归根到底就是能不能尽快建立交付的信心，跟个人能力、产品属性、研发流程都有关。其实是个认知问题
最后，还是要说，任何事物都无法背离内在规律，一个运行稳定，健壮，耐造的系统，必然是会要经过各种磨合、内外部各种问题锤炼才可能达成的。
你以为的快速交付、一战功成，哪有什么岁月静好，不过是有人替你负重前行罢了。只是这个负重的可能是前期的开发人员、也可能是测试人员、或者运维人员，抑或最后，靠用户扛下所有！
----------------------
软件测试体系化技能提升课已上线，欢迎关注
也欢迎关注秋草的公众号，秋草说测试 ，持续技术分享输出~
随时随地看视频
