深度故障复盘的几点思考

深度故障复盘是今年项目质量改进的一个重点举措。对一个故障的深度故障复盘主要基于以下几个方面：

1、故障的现象和原因

2、影响范围

3、研发泄露原因

4、测试泄露原因

5、故障解决说明

基于上述的分析，分析出故障的属性分类（基本功能、性能、易用性），故障引入来源（代码重构、解决故障、新增需求、历史遗留），故障引入环节（需求澄清、需求研讨、开发实现），故障控制环节（测试方案设计、测试用例开发、代码走查、故事验收、CI自动化防护、系统测试）以及是否能自动化，最终输出满足SMART原则的改进措施。

通过故障引入环节的分析，可以挖掘出团队在需求管理环节出现的一些问题，比如：场景分析不全、性能效率分析不足、波及影响分析不足、兼容性分析不足等。这就是一个对团队需求环节的一个反馈。通过故障控制环节的分析，可以挖掘出团队在测试用例开发、代码走查、故事验收等质量保证体系环节中的一些问题。从本月做的13个深度故障复盘的结果来看，就明显的反映出团队代码走查活动一些明显的问题。

举例说明一下：

1、QA参与了团队的代码走查，但参与过程中很多问题并未及时感知到。

比如：代码中新增加了一个常量的定义。这些常量往往意味着一些边界，需要在验证过程中增加一些边界的测试。而如何做边界测试，对于团队也是一个权衡。我们可以在UT层去做边界测试的自动化验证，也可以在FT层或者ST层去做自动化或手工的测试验证。采取哪一种方式，在于团队对于测试性价比的考虑。比如：对于一个配置项的合法性校验，可能在UT层做，相较于其他层做就能达到事半功倍的效果。所以，团队的测试是要有分层的自动化体系，UT或者FT、ST根据投入产出比相互补位，来确定团队的分层测试策略。通过这种方式制定的团队分层测试策略才具备更大的落地的可能性。

比如：QA需要有敏锐的感知能力，嗅到代码的改动对一些既有的功能场景的影响。之前团队在新增需求开发的用例中，已经做了一个改进，要求开发新增波及功能点的测试用例。但当一个系统比较大的时候，一个功能往往很大，如果不能精确的说明到某一个场景点，只是对一个功能点做一个基本功能的回归测试，极有可能无法覆盖到代码真正波及影响到的那个点；而如果要对整个功能做非常全的覆盖，除了时间成本的权衡，还有可能因为已有用例不全而导致波及测试的遗漏。通过故障复盘，给予团队QA一个反馈，触发大家去思考如何通过参与代码走查这项活动，更有效的去对代码的波及功能做准确的覆盖验证，提升代码的质量，埋下种子，静待花开。

2、团队做了代码走查，但很多问题没有及时走查出来。

比如：代码重构前，代码中有一个空指针的保护，修改后的代码去掉了这个空指针的保护。团队走查时并未发现，导致泄露了一个空指针故障给外部，给产品各个环节都带来了不少工作量，这个案例反馈出两个问题：

（1）、团队在做代码走查的时候，重点的关注点是在修改后的代码，容易忽略修改前的代码，这个信号提醒团队，走查代码时，需要两边同时做关注。代码走查，很多团队都实践过，有的团队从中受益良多，有的团队却认为似乎也没有什么效果。就是因为实践过程中细节和手法上的差异，是实践活动是否有效的关键。因此，我们在做的过程中，如果能够通过故障复盘得到一些反馈，就能不断去思考和持续改进。

（2）、团队在做代码重构的时候，往往并不是严格意义上的重构，因为重构前后改变了代码的逻辑，从而导致一系列的问题，这也是大家不愿意做重构的原因。我们常常说，在重构前，必须要先对代码编写单元测试，在有测试保证的情况下，再去做重构。奈何代码的复杂度已经很高，直接去编写单元测试是一件非常困难的事情。但重构又有风险会引入新的问题，所以我们尽可能去避免做重构，在原来已经非常复杂的代码的基础上继续修修补补，最终在我们的工程里面产生了越来越多的遗留烂代码。想要打破这样一个恶性循环，需要我们的开发人员，具备clean code的意识，提升对代码好坏的品鉴能力，并逐步掌握一些重构的技能和技巧（包括工具，好的工具会让大家的工作效率得到极大的提升），并掌握更多的编写单元测试的技巧去隔离和解依赖，技能上去了，才能减少犯错的可能性，大家看到了好处，得到了正面反馈，才能更有信心更进一步的去做。故障复盘的活动，就像一个榔头棒，敲打敲打才能深化大家的认识，才有可能让大家将这些代码实践活动进行落地。否则，只是制定一系列的编码规范，而没有让项目成员主动有意识去进行实践，是无法真正做到实践落地的。

综上所述，我们在制定一系列的改进措施的时候，往往只见树木不见森林，产品级的敏捷实践活动，涉及到从产品-项目-团队的各项管理和技术实践活动，究竟哪一些实践活动解决项目的痛点是有效的，往往需要系统的来对项目的痛点进行分析，找到翘起地球的那个杠杆解。深度故障复盘就像一个支点，如果这个支点利用得好，我们就能够从这个支点出发，深挖根因，并以此为出发点去制定有效的改进措施。同时，每个月的故障复盘情况，又是对前一个月的各项改进措施是否有效的一个极有价值的反馈，基于这样一个反馈环去做小步、持续改进，我们才能切实的解决产品的质量问题。