质量保障体系的生命周期

有同学在公众号后台留言，问了这样一个问题：

搭建质量保障体系，有没有从零到十的落地步骤，比如在项目的不同阶段该侧重哪些方面？

老实说，这个问题让我眼前一亮，这段时间难得的一个好问题。互联网上的技术文章大多分两种类型：一种是纯技术细节或者工具使用步骤，另一种则是高屋建瓴式的体系总结，有头有尾，却少了过程，看的人有种隔靴搔痒的感觉。

技术细节或者工具使用步骤，对新人来说很适合，毕竟新人几乎不可能有机会去做体系化的东西，大多都是干的螺丝钉搬砖的活儿。高屋建瓴式的体系总结，更适合有丰富经验或者已经在管理岗上的人，需要更近一步做体系优化和效率提升。

这篇文章分享一些我对于质量保障体系生命周期的理解和实践，仅供参考。

首先说明一点，如果你所在公司或团队的业务类型是To B且项目交付制的一锤子买卖，那没必要花费太多精力在体系搭建和优化上面，项目能达到交付的验收标准即可。

如果是自研产品比如Iaas、PaaS、SaaS，或To C的产品，因为产品的生命周期较长，且企业的利润大多以这些产品为载体来转化，那很有必要搭建体系化的质量保障体系。因为时间足够长且资源相对充足，才有足够的空间给你去搭建和不断优化。

按照我的实践经验以及对质量保障体系的理解，我会将一个项目/产品分为四个阶段，分阶段来说明各个不同阶段，在质量保障方面应该侧重的点。

产品初创期

产品初创期的一大特点是需求迭代快，功能变更的频次和范围更大，且临时插入需求的情况更常见，因此在这个阶段不宜投入大量资源在质量保障的体系搭建上，而是把精力和资源重点放在需求的吞吐率方面。

在产品初创期，我个人的实践经验是，质量保障的下限是功能+接口，做好功能测试，保障产品的基础质量。在时间和资源允许的情况下，建立基本的测试流程和规范，做好线上监控跟进以及应急响应，再辅以复盘优化机制即可。

产品成长期

当产品进入成长期，会带来这几点挑战：流量增长幅度大、业务复杂度提升、系统架构也会进一步变得复杂起来。对应在质量保障的技术侧，则需要考虑开展性能测试、自动化测试、环境稳定性治理，一句话概括就是基础技术平台搭建。

性能测试要解决的是线上流量增长带来的容量不足和稳定性问题，自动化测试要解决的是重复测试环节的低人效问题，环境稳定性治理则是面对越发复杂的系统架构和业务迭代，测试环境数量不足或者环境不够稳定会极大的影响正常的测试活动开展。

在这个阶段，除了测试团队自己需要发力在基础技术平台建设以及进一步完善研发测试流程规范之外，还要向前一步，与其他技术团队达成良好的沟通协作。比如在需求评审、用例评审、变更风险评估以及线上监控体系完善方面，这些都需要和产品、研发、运维通力合作才能拿到结果。

产品成熟期

产品进入成熟期后，意味着需求迭代变更和流量增长进入了稳定的节奏，这背后也意味着公司在这个方向上的业务重点从业务增长变为精细化运营，与之对应的，就是对产品质量、线上服务稳定性以及研发效能有了更高的要求。

对测试团队来说，这个时候的工作重点就是测试左移右移，也就是质量保障体系的进一步完善和提升单位人效阶段。左移需要从需求阶段开始加强评审和变更风险应对，右移则是重点关注线上交付质量以及线上问题的应急响应和事后复盘改进落地。

左移和右移中间的测试过程，重点则是加强流程管控、数据度量以及效率提升。细化的话，有很多事情要做，比如代码分支管理、项目管理、版本管理、CICD流水线(性能和各种自动化测试融入交付流水线)建设等一系列事项。

同样，这个阶段要完善质量保障和管控体系，需要进一步加强和产研设团队的合作，更需要领导认可以及资源支持，否则就会成为不上不下的尴尬境况。

产品衰退期

最后一个阶段，即产品衰退期，这个阶段需求迭代量会明显减少，对应的技术团队工作量会大幅度降低。其实产品衰退期可以换一种称呼，业务衰退期，很典型的例子就是这两年很流行的开猿节流+降本增笑。

比如拼多多，自从海外的temu项目上线之后，国内的产品几乎不怎么迭代了，只有少量的人在维护日常运转，不出大问题即可，这也是另一种意义上的衰退期。

其实产品衰退期也可以理解为增长停滞和利润下滑，核心的资源都会转移到新业务上，对测试团队来，就是保证已有的工作成果和质即可，不犯错就是无功也无过。

总的来说，质量保障体系建设的生命周期，是和公司的业务发展高度绑定的。技术只有跟随业务支撑业务发展才能体现出价值，当业务和产品进入衰退期，自然就不需要投入大量资源在技术方面。

因地制宜，时移势易，审时度势，才是成年人做事的根本法则。