前言
写这篇文章的初衷，是前几天在团队内部进行了一次缺陷和用户反馈建议的复盘归因分享，略有所得。
正好昨天看到chenkl老师的一篇文章：《团队交付质量如何评估》。其中讲到的很多点如缺陷趋势图、交付时长、线上BUG逃逸率、用户反馈等，给了我很多不一样的启发。
这篇文章，我想来聊聊，如何通过复盘归因，来提高交付质量。
软件交付质量
在日常的工作流程中，比较通用的流程如下图所示：
从质量保障和交付的角度来讲，软件交付生命周期中大体可分为如下三个阶段：
需求设计质量
这个阶段包括原型图、PRD文档、交互设计、技术方案、测试用例等几项重要产出物，当然他们有一定的前后依赖关系。
我们谈软件交付质量，不可避免的要从它的源头说起，而源头就是需求和设计阶段要做的事情。
如上图所示，我们为什么需要做大量的评审工作呢？因为如果在源头存在问题，那么研发过程和后面的用户使用质量，就无从谈起。方向错了，就全错了。
评审最大的作用就是集各个角色(产品&研发&测试)从不同角度对需求设计进行解读理解，提出疑问和建议并进行修正。
确保在最开始确定方向和需求细节方面，尽可能降低或者避免遗漏及不合理带来的质量交付风险。
研发过程质量
有句话怎么说来着？“软件质量是构建出来的，不是测试出来的”。
测试的本质是验证研发交付的产出物是否达到需求设计及预期的标准。并不能直接带来质量的提升，只能通过种种手段多维度的去验证是否达标，并通过流程规范、度量标准等去保障最终的交付物达标。
因此，我们常说的各种测试技术手段，都是验证和保障交付质量的手段，而不是构建质量的手段。
用户使用质量
用户使用质量，指的是软件线上发布后，我们对用户使用过程进行追踪并采集数据进行评估度量的过程。
常见的评估维度有线上缺陷逃逸率、客诉工单、用户反馈建议、数据埋点等。
具体内容可参考chenkl老师的《团队交付质量如何评估》，这里不做过多的赘述。
复盘归因的价值
为什么要复盘归因
之前有人问我，软件测试的本质是什么？我考虑良久，给出的答复是“质量+效率”。
先保障质量可控，再提高过程效率，通过节省下来的资源去投入到提高质量的过程中。
上面的内容提到了软件交付生命周期以及软件交付质量在不同阶段的产出物，在每个环节都需要通过评审、检查、度量、验证、回归等手段来保障交付质量。
但这些手段只能保障在每次迭代的生命周期中，软件交付质量处在一个可控的范围内。长期来看，并不能达到提高交付质量以及过程效率的目的。因此，复盘归因的价值就体现了出来。
通过对过程和交付结果以及线上用户使用质量进行跟踪度量评估，找到出现问题的原因、解决方案，
并将其中可复用的进行归纳总结，通过流程规范、技术优化、文档培训等方式融入贯穿交付过程，最终达到提高交付质量和效率的目的。
如何开展复盘归因
先看下面这张流程图：
我们在谈到软件交付质量的时候，分了三个阶段，每个阶段都有不同的手段去测试验证，也有各自的产出物。比如：
需求设计阶段：原型图、PRD文档、交互设计
研发过程阶段：单测覆盖率、codereview记录、bug列表
用户使用阶段：线上问题list、用户反馈list、数据埋点结果
整体的复盘归因过程，可以拆解为下列几个步骤：
- 对不同阶段的过程及产出物进行复盘评估；
- 找到做的不好的地方或者不合理的手段方式；
- 评估它的操作和背后的原因以及当时的解决方案；
- 思考问题：怎么做才能让过程和交付结果变得更好；
- 将更好的方式进行归纳总结并将其融入交付过程的过程；
- 推广落地实践并进行度量评估，验证其是否有效，并不断复盘归因；
复盘归因的真正目的
上面我们聊了交付过程的三个阶段，也聊了为什么要进行复盘归因以及它的过程，那复盘归因的真正目的是什么呢？
其实答案在上面已经说了，这里我想从测试的角度加入一个新的词：收敛。
测试的本质是什么？我觉得在当下的应用实践中，应该是保障质量可控→提高过程效率→确保问题收敛。
