CheckList在测试中的落地实践

标签：同学落地验证 CheckList 技术内容测试

前天写了一篇CheckList对交付质量价值的文章，后台有同学留言，问了这三个问题：

这篇文章基于上述三个问题，就CheckList在测试过程中的落地实践，谈谈我的一些经验和理解，供大家参考。

首先来聊聊谁来主导的话题。

CheckList是一种应用于软件产品研发过程中各环节，验证交付质量的方法，同时它也是一种风险预防机制。

从软件工程的角度来说，其核心目的就是控制风险，聚焦质量，因此CheckList的作用不言而喻。

那么由谁来主导呢？其实从我的角度来理解，CheckList没有谁主导谁辅助的说法。

比如从项目管理角度，管理者需要考虑项目进度，项目质量以及是否存在风险，那么他就可以采用CheckList这一策略，通过定时的站会或者项目进度沟通会来掌握相关信息，评估是否存在影响项目进度和质量的风险，并进行预防。

从测试同学的角度来说，我们的岗位职责就是质量保障，所有可能导致风险的点都需要评估且进行充分验证。CheckList作为一种风险预防机制和验证方法，也是我很推荐测试同学在日常工作中去实践应用的。

在真实的项目实践和工作场景中，绝大多数工作都是需要多方协作配合才能完成的，因此只要有相同的目标，保持大体一致的迭代节奏，遵循一致的工作规范即可。至于采用哪种方法，见仁见智吧。

给大家列举一个我以前工作中的案例。

当时我管理的团队有一块内容是负责用户业务的质量保障工作，具体负责人是一个测试小姑娘。

有一次用户服务线上由于缓存数据同步出现了一点问题，导致部分用户下单失败(下单时用户token更新)，虽然只影响了一小部分业务，且不到一分钟就恢复正常了，但线上问题无论多小都值得重视起来。

回头复盘时候，通过分析得出的问题根因是：由于版本迭代，用户下单逻辑校验登录态规则稍有变化，发布后没有及时更新定时Job配置，导致检测到逻辑变化而自动同步了(原定规则是凌晨更新)。

我给负责用户业务的小姑娘提了一个建议：每次版本迭代，将改动项和影响范围梳理出来，并对需要进行配置更新及相关操作的点都罗列出来，在代码发布到UAT和PRO环境前都和开发进行确认并及时验证，尽可能将风险快速暴露出来。

后续这个方法我推动到了整个测试团队，并将相关的CheckList进行了统一维护，通过自动化的验证方式融入到发布流水线中，这样也能提高发版和验证效率。

其实日常工作中CheckList的案例有很多，典型的就是线上发布前的数据备份，以及回滚恢复机制。

CheckList的制定逻辑其实很简单，大体按照如下步骤即可：

以上内容，就是我对于CheckList策略在测试过程中落地实践的理解和一些经验之谈，仅供参考。

最后，聊点题外话，当然也是和软件测试相关的内容。

我坚持写技术文章快八年了，最初是在博客园，到现在累计了500W+的阅读量，自认为数据还算不错。运营这个公众号也快六年了，写了不少原创技术文章，关注我比较早的同学应该都知道我的内容质量如何。

自从开通留言功能后，有不少同学反馈说，日更的内容，大多集中在某一个很细节或者很明确的问题上，想了解更多比较全面和体系化的知识。

其实体系化的内容，以前也写过不少，估计同学们很少关注公众号主页的标签分类，当然历史文章确实有点多，翻起来很麻烦。

回到正题，我在公众号新建了一个付费订阅合集，合集的内容结构如下图所示：

这个付费技术合集，分为三大模块，共计10篇文章，每周三｜周五更新，一次订阅，终身免费。内容主要涵盖性能测试、自动化测试、以及测试技术专项治理。

本付费技术合集的内容，整合我过往所有技术文章，从中梳理和抽取了精华内容，加上我近几年大量的咨询和实践案例，不废话，直接上干货，后期不排除新增内容和答疑部分。内容亮点如下：

合集中的每篇文章，我都会在开头标明内容大纲和学习路径，帮助大家更好的理解这些体系化的知识。

写作本付费合集的目的：解决大家在技术层面存在的缺陷，为大家打开更广阔的技术视野，帮助广大测试同学建立完善的技术知识体系，以便在职场和个人职业发展中有更好的竞争力。

本周五更新第一篇，感兴趣的同学可以订阅。当然，公众号我依然会继续保持更新。

标签：同学,落地,验证,CheckList,技术,内容,测试
From： https://www.cnblogs.com/imyalost/p/18222151