干货｜从故障复盘看产品质量防线

点击上方“中兴开发者社区”，关注我们

每天读一篇一线开发者原创好文

   故障复盘作为质量回溯的一个重要环节，笔者作为QA之前一直未能加大重视。直到某天某位敏捷教练的一句话：通过故障复盘，可以倒推出现质量问题的某个环节，甚至某个具体的点，也可以让你更加清晰地认知到在需求进入开发到交付整个过程中，质量防御不足的地方。因此笔者借助扎据开发团队内的优势，简要画出了笔者所在团队从需求进入到需求交付整个开发和测试流程中的质量防线，如下图1-1所示。

      说明在前：

      笔者认为，开发和测试在敏捷过程中应该是处于平等地位，同时进行的。简要阐述笔者的看法，就是开发同事在编写代码实现功能，测试人员也应该在编写测试用例（理想很丰满，现实很骨感，笔者虽这样认为，事实上笔者自己还有所欠缺，未能完全实施）。因此下图中，从特性拆分故事后划分了开发和测试两条线，一起走向最后的特性交付。

1、简要说明产品开发到交付的质量防线点

       ① 从原始需求进入到特性拆分为故事，需要经过需求分析和特性分析。需求分析结果表明是否承接该需求进行开发，而特性分析结果表明该需求如何实现。因此，如下图所示在原始需求和特性后设置了两处防线（防线1、2）：需求分析和特性分析。此处作为入口处，若是防线缺失或防御不足，将会导致后续的开发实现和测试、验收环节出现偏差，交付的产品出现与需求严重不一致的纰漏。

       ②当特性拆分为故事后，开始进入开发和预测试环节。

       在开发环节，团队需要就需要实现的功能进行方案设计和研讨，其后才是编码实现。针对开发方案，如下图所示设置了防线3.1.1：开发方案评审。方案评审通过后，在开发实现后又设置了防线3.1.2：代码走查和防线3.1.3：UT测试。开发环节作为功能实现环节，若是防线缺失或防御不足，将会出现最终实现的功能出现缺陷。

       在预测试环节，与开发环节对等，也需要进行测试方案评审（防线3.2.1）、AC评审（防线3.22）和用例评审（防线3.2.3）。在预测试环节，所有防线都应该BA、DEV和QA一起参加，尽量避免场景遗漏、测试方案不足、测试用例缺失等带来的开发功能交付后仍存在缺陷的问题。

       ③当开发环节和预测试环节完成后，基础功能已经交付，开始进入故事验收和特性预交付。在特性交付前，应进行功能测试和系统测试，以及验收完的功能进行演示，以保证交付产品功能完善，遗留故障少。如下图所示，设置了防线4：FT、防线5：ST和防线6：showcase（演示会）。在此环节，防线6：showcase应该团队所有成员一起参加，做特性交付前的功能检查和测试完备性检查。

       经过如上几处防线，可以提升交付产品质量，尽可能减少产品与用户需求不符，实现与设计相左，交付产品缺陷多等问题。

2、如何从故障复盘看产品质量防线缺失或质量防御不足

       在1中，简单讲述了如何在产品需求进入到交付产品整个实现环节中设置质量防线。在此节，我们来看看当产品交付后发现缺陷（故障），如何分析质量防线缺失或质量防御不足，以及如何加固防线，提升产品质量，做到产品质量跟踪回环。

       如下图所示，通过故障复盘，我们应该对每个质量缺陷从引入环节和控制环节（如下图已表明引入环节和控制环节，引入环节主要包括：需求分析、开发实现；控制环节主要包括：测试设计和测试执行）分析质量防御不足的原因。

       比如用户使用产品功能与提出需求时不一致，我们可以清晰地定位引入环节中防线1和2未能起到质量防御作用，此时应对防线1、2进行加固；

      比如用户使用的产品出现基本功能错误，我们可以将引入环节定位划定在开发实现质量防御不足，控制环节定位查看是否测试方案设计和测试执行出现质量防线缺失或防御度不够；

      通过故障复盘，除了分析质量防线缺失或防御不足外，我们还可以针对故障复盘的数据进行质量防线增设。如下图所示的引入环节防线7：波及分析和控制环节防线8：故障用例补充。由此，可以加强质量防御，尽量减少重复故障发生和降低故障泄露率。

      综上所述，清楚地了解质量防线地位置与作用，对于质量把控具有重要的意义。故障复盘作为一个质量回溯的重要环节，所有团队成员都应加强重视，复盘的目的不在于补漏而在于预防，通过故障复盘挖掘现有防线缺失的地方，加强和增设质量防线，以提升产品质量。

      谓之：非止排难於变切，亦将防患於未然~

                                              图1-1 质量防线