CheckList在测试中的落地实践
前天写了一篇CheckList对交付质量价值的文章，后台有同学留言，问了这三个问题：
- CheckList是否有详细的案例说明？
- CheckList的整体制定逻辑是什么？
- CheckList策略应该由项目还是测试主导？
这篇文章基于上述三个问题，就CheckList在测试过程中的落地实践，谈谈我的一些经验和理解，供大家参考。
谁来主导CheckList执行？
首先来聊聊谁来主导的话题。
CheckList是一种应用于软件产品研发过程中各环节，验证交付质量的方法，同时它也是一种风险预防机制。
从软件工程的角度来说，其核心目的就是控制风险，聚焦质量，因此CheckList的作用不言而喻。
那么由谁来主导呢？其实从我的角度来理解，CheckList没有谁主导谁辅助的说法。
比如从项目管理角度，管理者需要考虑项目进度，项目质量以及是否存在风险，那么他就可以采用CheckList这一策略，通过定时的站会或者项目进度沟通会来掌握相关信息，评估是否存在影响项目进度和质量的风险，并进行预防。
从测试同学的角度来说，我们的岗位职责就是质量保障，所有可能导致风险的点都需要评估且进行充分验证。CheckList作为一种风险预防机制和验证方法，也是我很推荐测试同学在日常工作中去实践应用的。
在真实的项目实践和工作场景中，绝大多数工作都是需要多方协作配合才能完成的，因此只要有相同的目标，保持大体一致的迭代节奏，遵循一致的工作规范即可。至于采用哪种方法，见仁见智吧。
CheckList的落地执行案例
给大家列举一个我以前工作中的案例。
当时我管理的团队有一块内容是负责用户业务的质量保障工作，具体负责人是一个测试小姑娘。
有一次用户服务线上由于缓存数据同步出现了一点问题，导致部分用户下单失败(下单时用户token更新)，虽然只影响了一小部分业务，且不到一分钟就恢复正常了，但线上问题无论多小都值得重视起来。
回头复盘时候，通过分析得出的问题根因是：由于版本迭代，用户下单逻辑校验登录态规则稍有变化，发布后没有及时更新定时Job配置，导致检测到逻辑变化而自动同步了(原定规则是凌晨更新)。
我给负责用户业务的小姑娘提了一个建议：每次版本迭代，将改动项和影响范围梳理出来，并对需要进行配置更新及相关操作的点都罗列出来，在代码发布到UAT和PRO环境前都和开发进行确认并及时验证，尽可能将风险快速暴露出来。
后续这个方法我推动到了整个测试团队，并将相关的CheckList进行了统一维护，通过自动化的验证方式融入到发布流水线中，这样也能提高发版和验证效率。
其实日常工作中CheckList的案例有很多，典型的就是线上发布前的数据备份，以及回滚恢复机制。
CheckList策略的制定逻辑
CheckList的制定逻辑其实很简单，大体按照如下步骤即可：
- 评估风险，确认影响范围和检查点；
- 针对检查点将验证手段列举出来，变更时及时验证；
- 按照业务域和应用进行点对点或点对多匹配，统一维护；
- 将上述过程推动落地成为研发测试流程的一部分，形成质量门禁之一；
- 将手动执行CheckList的方式变为自动化的方式，利用CICD或者融入发布流水线；
以上内容，就是我对于CheckList策略在测试过程中落地实践的理解和一些经验之谈，仅供参考。
最后，聊点题外话，当然也是和软件测试相关的内容。
我坚持写技术文章快八年了，最初是在博客园，到现在累计了500W+的阅读量，自认为数据还算不错。运营这个公众号也快六年了，写了不少原创技术文章，关注我比较早的同学应该都知道我的内容质量如何。
自从开通留言功能后，有不少同学反馈说，日更的内容，大多集中在某一个很细节或者很明确的问题上，想了解更多比较全面和体系化的知识。
其实体系化的内容，以前也写过不少，估计同学们很少关注公众号主页的标签分类，当然历史文章确实有点多，翻起来很麻烦。
回到正题，我在公众号新建了一个付费订阅合集，合集的内容结构如下图所示：
这个付费技术合集，分为三大模块，共计10篇文章，每周三｜周五更新，一次订阅，终身免费。内容主要涵盖性能测试、自动化测试、以及测试技术专项治理。
本付费技术合集的内容，整合我过往所有技术文章，从中梳理和抽取了精华内容，加上我近几年大量的咨询和实践案例，不废话，直接上干货，后期不排除新增内容和答疑部分。内容亮点如下：
- 从零到一的技术落地经验
- 从一到十的技术体系建设案例
- 从十到百的技术发展和演进路径
合集中的每篇文章，我都会在开头标明内容大纲和学习路径，帮助大家更好的理解这些体系化的知识。
写作本付费合集的目的：解决大家在技术层面存在的缺陷，为大家打开更广阔的技术视野，帮助广大测试同学建立完善的技术知识体系，以便在职场和个人职业发展中有更好的竞争力。
本周五更新第一篇，感兴趣的同学可以订阅。当然，公众号我依然会继续保持更新。
