如何组织一次有价值的业务巡检

原创郝路遥转转QA

1.背景

随着业务的快速迭代，开发自测需求与QA测试的需求比例相当，对于开发自测的需求，需求质量我们无法把控，并且随着自测需求的增多，QA对业务的熟悉程度也会出现断层；
部分业务整体已趋于稳定，迭代较少，但线上偶尔会出现一些历史遗留问题，导致运营同学在使用相关功能时需要找开发同学临时高优处理一下；
随着业务单量的不断增加，我们也越来越重视NPS，体验类的问题会严重影响用户的使用体验和拉低NPS，而良好的交互体验更有利于提升NPS和留存用户；

基于以上的问题，我们会定期组织开发同学一起进行业务巡检，希望通过业务巡检来解决这些问题，提高系统的可用性，减少线上问题；通过巡检可以让大家从用户的角度来了解业务，体验业务，从而提升用户体验；最后，也希望通过巡检来提高大家的质量意识，大家共同为质量负责！

2.巡检方式

在组织巡检之前，我们一直在思考两个问题，那就是如何让大家更加积极地参与巡检以及如何能提升巡检的效率？俗话说得好，适合自己的才是最好的，最终我们决定基于不同的业务特征，来组织不同形式的巡检。所以在介绍巡检方式之前先简单地介绍一下我负责的两个业务，以下分别以A业务和B业务代称。

2.1.A业务

1）业务流程

2）业务特点

业务流程相对简短单一，前端交互类功能较多。

3）业务现状

整体业务已趋于稳定，主要以运营为主，项目迭代相对较少，整体功能改动较小。

2.2.B业务

1）业务流程

3）业务特点

流程复杂多样，每条分支都是单独的业务逻辑

4）业务现状

业务处于快速发展阶段，迭代周期短，功能改动频繁

综上，根据二者业务特点，考虑到A业务流程相对简单，并且case有时会限制住大家的思维，所以最终确定采取自由巡检的方式，这样能更好地模拟用户的使用习惯，去发现问题。B业务流程比较复杂，如果自由巡检，可能无法覆盖全部流程，所以最终采取提供case的方式，通过case来引导大家尽可能覆盖更多的场景，能更好的从业务角度去发现问题。

3.关注点

本次巡检主要从功能、页面、交互等方面为关注点进行的

功能：各功能的完整性
页面：展示完整，无遮挡
交互：页面、功能之间的交互，站在用户角度，是否可接受，是否有可优化的空间

4.巡检计划

4.1.明确巡检范围

首先需要保证主流程的准确性，再按照业务模块进行划分，梳理巡检范围，然后再根据模块，细化需要关注的功能模块的各实现效果。

以下是划分的业务模块，巡检需要覆盖的范围：

模块划分后，则进行具体的模块整理，针对不同的巡检方式，分别进行了不同的整理。

4.2.提前进行业务梳理

A业务：

A业务虽然采取自由巡检的方式，但是大家对各个模块并不是完全熟悉，所以提前梳理业务流程，巡检前进行分享，以便在巡检前能先熟悉业务，更深入地走查业务流程。

B业务：

提前整理B业务的巡检case，在巡检前分别给大家创建不同的巡检case的测试计划，在巡检过程中提供参考，并逐条验证。

4.3.巡检频率

每周安排一次集中巡检，时长1~2小时，QA、RD、FE共同参与。

4.4.QA的职责

每次巡检会安排2个值班QA，主要负责解答case和记录巡检问题，巡检结束后针对提交的问题进行跟踪解决及验证。

5.问题记录

问题记录：以bug形式记录，提给对应开发同学。

问题跟进：关注问题的解决进展，验证回归。

问题总结：定期汇总问题类型，分析原因，总结经验，方便后续类似功能实现时，清楚需要重点关注的点有哪些，避免同样的坑重复踩多次。

通过对问题的汇总，问题主要集中在编码错误、用户体验、产品设计、系统兼容上，而用户体验的问题主要集中在小程序上。因此，后续在评审阶段，会更加关注产品设计的合理性，在避免日常工作中，会加强对小程序端的验证，以此减少体验类问题的产生。

6.收获

巡检中，最大的收获就是角色的转换，首先作为一名QA同学，需要保证各功能的准确性，完整性。其次，我们也是用户，需要站在用户的角度去考虑产品的合理性。对于业务巡检这件事后续我们也会坚持去做，不轻易放过任何一个线上问题，把好产品的最后一道质量关。

继续滑动看下一个