CheckList 对交付质量的重要性
![CheckList对交付质量的重要性](https://static001.geekbang.org/infoq/4e/4e1dda3a22ea7d4744bd71f6bd479ca0.webp)
前几天辅导一位星球同学,聊到了控制风险。这位同学说,他们现在处在一个资源紧张,需求迭代快,发布频繁且版本管理混乱的状态,导致线上系统经常出问题,问我有什么短期有效的方法。他也列举了几项自己思考出来的可能行之有效的的方法,如下:
推动自动化测试落地,节省人力和时间资源;
制定质量管理的 SOP,让产研设各个团队遵守;
招专业的项目经理,将版本和项目管理管控起来;
设置质量门禁,将每个环节准入准出标准定下来并严格执行;
上述这几项方法对提升交付质量有效果吗?答案是肯定有。但短期内能解决线上系统经常出问题的状况吗?很难。原因也不难理解,无论是自动化测试,还是质量门禁、质量管理 SOP 或者是专门的版本管理和项目管理,都需要投入大量的资源和时间,才能逐渐产生效果。
短期内面临的最大困境,就是线上系统出问题,这才是优先需要考虑并解决的。和他聊完这些问题后,我给他的建议只有一个:控制变更风险,执行 CheckList 机制。
据不完全统计,线上系统出问题背后的绝大多数原因,是变更导致的。特别是从 UAT 环境到线上环境,这个过程因为要进行大量的变更操作,比如数据库表结构变更,数据变更,应用配置参数变更,应用白名单,缓存更新,以及版本迭代相关的业务配置更新,都可能导致线上系统出现问题。
但变更控制很多时候在技术团队内部会被下意识忽略,原因在于:无论是开发环境还是测试环境,一方面变更控制流程几乎没有,随意变更,反正出了问题也不会导致什么直接损失。另一方面变更控制和评审需要投入一定的时间精力,且无法产生直接有明确数据的正向收益。长此以往,就听之任之。
从软件工程角度来说,变更控制其实就是风险控制,这样是有助于提升软件产品质量的,技术同学或多或少都明白这点。但推动这件事落地和很好的执行,有时候是个吃力不讨好的活儿。甚至在有些企业和技术团队内部,负责质量和稳定性的团队,经常沦为背锅侠,也挺悲哀。
什么是 CheckList?从字面意思理解,CheckList 就是检查清单,即每次变更前罗列出所有变更项和可能导致的风险,并针对性进行检查和预防。这里的变更可以适用于多个环节,比如开发提测、线上发布前,都可以将变更项罗列出来,逐一检查比对,确认是否存在风险和漏洞。
对测试同学来说,CheckList 是控制变更风险的一种手段,在实际工作中可以是多种形式,比如思维导图和 Excel 表格。下图是一个上线发布前的 CheckList 思维导图:
![](https://static001.geekbang.org/infoq/6f/6f42fa41d8b8c826320b97a667cfbe8e.png)
其中,每个二级检查项还可以进行细分,且不同的检查项之间存在依赖和递进关系。比如:风险预案机制是为了控制风险范围,备份和回滚恢复机制可以视作风险预案机制的一部分。
针对 CheckList 进行扩展的话,还可以通过设定发布窗口来控制发布频次,由测试同学主动去 owner 项目进度和版本。除此之外,线上问题频发,还需要通过复盘机制来改进优化,不断发现存在的问题,不断解决问题。
长期来说,只有先控制好风险的范围和影响程度,针对性解决,后续的自动化测试、版本管理、项目管理、质量管理 SOP 才能顺利往下推进。
版权声明: 本文为 InfoQ 作者【老张】的原创文章。
原文链接:【http://xie.infoq.cn/article/c16e0ea84cb83f6df32a6a29d】。文章转载请联系作者。
评论