CheckList在测试中的落地实践
前天写了一篇CheckList对交付质量价值的文章，后台有同学问了三个问题：
- CheckList是否有详细的案例说明？
- CheckList的整体制定逻辑是什么？
- CheckList策略应该由项目还是测试主导？
这篇文章基于上述三个问题，就CheckList在测试过程中的落地实践，谈谈我的一些经验和理解，供大家参考。
谁来主导CheckList执行？
首先来聊聊谁来主导的话题。
CheckList是一种应用于软件产品研发过程中各环节，验证交付质量的方法，同时它也是一种风险预防机制。从软件工程的角度来说，其核心目的就是控制风险，聚焦质量，因此CheckList的作用不言而喻。
那么由谁来主导呢？其实从我的角度来理解，CheckList没有谁主导谁辅助的说法。比如从项目管理角度，管理者需要考虑项目进度，项目质量以及是否存在风险，那么他就可以采用CheckList这一策略，通过定时的站会或者项目进度沟通会来掌握相关信息，评估是否存在影响项目进度和质量的风险，并进行预防。
从测试同学的角度来说，我们的岗位职责就是质量保障，所有可能导致风险的点都需要评估且进行充分验证。CheckList作为一种风险预防机制和验证方法，也是我很推荐测试同学在日常工作中去实践应用的。
在真实的项目实践和工作场景中，绝大多数工作都是需要多方协作配合才能完成的，因此只要有相同的目标，保持大体一致的迭代节奏，遵循一致的工作规范即可。至于采用哪种方法，见仁见智吧。
CheckList的落地执行案例
给大家列举一个我以前工作中的案例。
当时我管理的团队有一块内容是负责用户业务的质量保障工作，具体负责人是一个测试小姑娘。有一次用户服务线上由于缓存数据同步出现了一点问题，导致部分用户下单失败(下单时用户token更新)，虽然只影响了一小部分业务，且不到一分钟就恢复正常了，但线上问题无论多小都值得重视起来。
回头复盘时候，通过分析得出的问题根因是：由于版本迭代，用户下单逻辑校验登录态规则稍有变化，发布后没有及时更新定时Job配置，导致检测到逻辑变化而自动同步了(原定规则是凌晨更新)。
我给负责用户业务的小姑娘提了一个建议：每次版本迭代，将改动项和影响范围梳理出来，并对需要进行配置更新及相关操作的点都罗列出来，在代码发布到UAT和PRO环境前都和开发进行确认并及时验证，尽可能将风险快速暴露出来。
后续这个方法我推动到了整个测试团队，并将相关的CheckList进行了统一维护，通过自动化的验证方式融入到发布流水线中，这样也能提高发版和验证效率。
其实日常工作中CheckList的案例有很多，典型的就是线上发布前的数据备份，以及回滚恢复机制。
CheckList策略的制定逻辑
CheckList的制定逻辑其实很简单，大体按照如下步骤即可：
- 评估风险，确认影响范围和检查点；
- 针对检查点将验证手段列举出来，变更时及时验证；
- 按照业务域和应用进行点对点或点对多匹配，统一维护；
- 将上述过程推动落地成为研发测试流程的一部分，形成质量门禁之一；
- 将手动执行的方式变为自动化的方式，利用CICD或者融入发布流水线；
以上内容，就是我对于CheckList策略在测试过程中落地实践的理解和一些经验之谈，仅供参考。