为什么要做缺陷分析
不论是在传统的软件开发流程还是敏捷开发流程中，缺陷的统计与分析都是软件质量保证的重要环节。
一些传统的缺陷统计和分析往往把重点放在缺陷数量的统计上，用于衡量开发和测试人员的KPI。例如某个功能模块出现了重大的bug，那当时负责开发的开发和测试都要出来“背锅”。
不能说这种方法是错的，但是如果把目的放在真正提高代码的质量上，缺陷的分析应该摆脱这种找人背锅的思路，回到真正的目的上来。一个缺陷的产生不能简单归结于开发的错误或者测试的漏测，还需要从产品设计，架构设计，用户体验等方面进行分析。
产品的质量是内建的，当代码完成的时候，质量就已经确定了。缺陷分析的价值应该体现在如何帮助代码开发过程中的持续改进中。
怎么做缺陷分析
前期准备
缺陷分析的前期准备工作主要体现在缺陷/Bug的记录上。
要做到后期有效的缺陷分析，很重要的部分其实是前期记录bug时的信息收集。
下面的一些信息都是必须要在创建和修复缺陷的时候记录下来的：
缺陷发生的功能模块
记录下缺陷发生在哪一个功能模。复杂的系统里面有很多功能模块组成，我们需要记录下尽可能准确的功能模块，也有可能缺陷发生在不同模块之间的交互中，例如不同微服务之间的业务通信，在service的provider和consumer的交互中出现问题。那这种交互也可以看作是一个特别的模块。模块的定义并不是固定的，目的是定位缺陷发生的位置。
缺陷的Root Cause
Root Cause可以理解为错误的根源。而这个根源指的是导致缺陷的原因。一些常见的root cause有：
- 编码错误：开发在写代码的过程中出现了错误，包括逻辑错误，场景分析的遗漏，功能未完全实现等等甚至是拼写错误。
- 其他缺陷修改引入：开发在修复其他某个缺陷的时候引入了当前的缺陷。这在日常的开发中是比较常见的问题。修复Bug时，要确保当前的修改对其他模块和逻辑的影响不是一件容易的事情。
- 其他新功能引入：开发在开发某个新功能（Feature）的时候引入了当前的缺陷。当一个新功能与原有的业务逻辑有很强的依赖性（Dependency）的时候很容易出现这种bug。
- 其他架构/Data Model/Service变化引入：这类型的缺陷主要出现在不同系统/服务之间协同开发的项目中。当前项目所依赖的外部系统/服务也在进行开发，这些开发带来的变化就有可能造成当前项目中出现缺陷。
- 需求理解偏差：这是一类比较特别的root cause，看上去和代码逻辑错误很类似。但还是有区别的，假设实际业务需求是A，开发人员的理解也是A，结果实现的是B，这是编码错误。如果开发人员的理解是C，实现的也是C，那就是需求理解偏差。这主要是为了考察开发和产品需求之间的沟通是否正确。
- 需求歧义：缺陷的产生有时候并不一定都是开发过程中产生的，也存在由于需求本身的描述不准确导致缺陷的情况。不过在实际的工作中，需求描述的粒度如何把握是一门艺术，同时也能看出一个敏捷团队磨合程度。需求歧义并不是说产品经理
深入分析
一个信息记录详细的缺陷，也为后续的分析提供了足够的信息支持。
一个深入的分析，可以从以下几个角度切入：
参与人员
缺陷分析可以以头脑风暴的形式来展开，参与的人员也不仅仅限于开发和测试人员，产品经理或者BA（业务分析）也可以参与到讨论中。
与code review结合
缺陷分析要深入，几乎难以避免的要去深挖代码，通过对代码的重新审视，抽丝剥茧的分析问题发生的原因。是初期的设计缺陷，还是实现时场景考虑的不完整，又或是代码结构的不合理，这些都是需要对代码进行review才能知道。
同时修复这个缺陷的代码也需要进行review。因为发生缺陷的地方，可能是一个业务上的难点，也可能是代码实现中的难点，缺陷的修复需要经过code review，这样有助于降低再次引起其他缺陷的风险。
对测试用例进行review
对于产品环境发现的缺陷，很有必要对相关的功能的测试用例进行重新审视。因为这个缺陷是测试活动的漏网之鱼。
一个在发布上线前没有被发现的缺陷，一定程度上可以说是escape from test。当然其中的原因是很多的。有可能是测试用例设计时场景路径考虑的不完全，又或者是团队对于真实业务数据的预估偏差，导致测试时没有把这个场景的优先级提高。因为测试的资源是有限的，一些优先级较低的场景并没有能够加入到regression的自动化测试中。
如果缺陷发生的场景没有测试用例覆盖，那需要针对这个缺陷增加测试用例，对于线上的严重缺陷，还需要增加相应的自动化测试用例加以覆盖。
产品/需求/设计相关
缺陷的引入还有可能和产品的前期需求设计相关。
有的线上缺陷可能是需求分析不充分导致的。更多的可能是需求的表达不清晰导致的开发测试理解偏差引入的。这就需要整个团队的关注，寻求一种大家都能够理解的需求描述粒度。
解决方案
经过了前期的准备和深入的分析，终于到了输出的时候。一个缺陷分析没有得到有价值的输出，前面做的再好也是浪费。一个针对缺陷分析的解决方案，就是这个有价值的输出。
缺陷分析的输出不是对缺陷的修复，而是避免同类缺陷再次出现的解决方案，这是一个内涵很广的东西，它可以包括，但是不限于以下的内容：
- 对产品业务需求/设计层面的改进
- 对系统架构层面的改进
- 对代码设计实现层面的改进
- 对测试用例设计方面的改进
- 对持续集成流程方面的改进
- 对于敏捷团队日常工作实践的改进
缺陷分析的解决方案是一个来源于缺陷，但是又能站的更高走的更远的，并且可以操作和追踪的解决方案。缺陷分析的整个过程中不用把思维局限在缺陷本身，而是可以从多个角度来看待一个缺陷。
最后，给大家一个小小的提示，缺陷分析要避免走向为缺陷找人背锅的方向，分析和讨论的过程中要关注事件本身，而不是强调某个人在过程的责任。因为质量是团队的责任，基于分析过程中发现的具体问题，大家一起提出建设性的意见，这样的持续改进才是敏捷的正确实践。
