CheckList 对交付质量的重要性

前几天辅导一位星球同学，聊到了控制风险。这位同学说，他们现在处在一个资源紧张，需求迭代快，发布频繁且版本管理混乱的状态，导致线上系统经常出问题，问我有什么短期有效的方法。他也列举了几项自己思考出来的可能行之有效的的方法，如下：

• 推动自动化测试落地，节省人力和时间资源；

• 制定质量管理的 SOP，让产研设各个团队遵守；

• 招专业的项目经理，将版本和项目管理管控起来；

• 设置质量门禁，将每个环节准入准出标准定下来并严格执行；

上述这几项方法对提升交付质量有效果吗？答案是肯定有。但短期内能解决线上系统经常出问题的状况吗？很难。原因也不难理解，无论是自动化测试，还是质量门禁、质量管理 SOP 或者是专门的版本管理和项目管理，都需要投入大量的资源和时间，才能逐渐产生效果。

短期内面临的最大困境，就是线上系统出问题，这才是优先需要考虑并解决的。和他聊完这些问题后，我给他的建议只有一个：控制变更风险，执行 CheckList 机制。

据不完全统计，线上系统出问题背后的绝大多数原因，是变更导致的。特别是从 UAT 环境到线上环境，这个过程因为要进行大量的变更操作，比如数据库表结构变更，数据变更，应用配置参数变更，应用白名单，缓存更新，以及版本迭代相关的业务配置更新，都可能导致线上系统出现问题。

但变更控制很多时候在技术团队内部会被下意识忽略，原因在于：无论是开发环境还是测试环境，一方面变更控制流程几乎没有，随意变更，反正出了问题也不会导致什么直接损失。另一方面变更控制和评审需要投入一定的时间精力，且无法产生直接有明确数据的正向收益。长此以往，就听之任之。

从软件工程角度来说，变更控制其实就是风险控制，这样是有助于提升软件产品质量的，技术同学或多或少都明白这点。但推动这件事落地和很好的执行，有时候是个吃力不讨好的活儿。甚至在有些企业和技术团队内部，负责质量和稳定性的团队，经常沦为背锅侠，也挺悲哀。

什么是 CheckList？从字面意思理解，CheckList 就是检查清单，即每次变更前罗列出所有变更项和可能导致的风险，并针对性进行检查和预防。这里的变更可以适用于多个环节，比如开发提测、线上发布前，都可以将变更项罗列出来，逐一检查比对，确认是否存在风险和漏洞。

对测试同学来说，CheckList 是控制变更风险的一种手段，在实际工作中可以是多种形式，比如思维导图和 Excel 表格。下图是一个上线发布前的 CheckList 思维导图：

其中，每个二级检查项还可以进行细分，且不同的检查项之间存在依赖和递进关系。比如：风险预案机制是为了控制风险范围，备份和回滚恢复机制可以视作风险预案机制的一部分。

针对 CheckList 进行扩展的话，还可以通过设定发布窗口来控制发布频次，由测试同学主动去 owner 项目进度和版本。除此之外，线上问题频发，还需要通过复盘机制来改进优化，不断发现存在的问题，不断解决问题。

长期来说，只有先控制好风险的范围和影响程度，针对性解决，后续的自动化测试、版本管理、项目管理、质量管理 SOP 才能顺利往下推进。