缺陷管理，一门关于质量内建的学问

既然无法完全阻止缺陷的出现，那如何确保已发生的缺陷得到有效的处理，如何利用已有缺陷来指导质量内建过程，是我们需要考虑的，也就是缺陷管理的内容。
敏捷测试原则中有一条是：预防缺陷，而不是关注缺陷的数量。在敏捷开发中，虽然我们采取了各种措施预防缺陷的发生，例如精准的自动化测试、代码检视、故事卡验收等等，但是并不能保证没有缺陷发生，一个零缺陷的产品也不现实。既然无法完全阻止缺陷的出现，那如何确保已发生的缺陷得到有效的处理，如何利用已有缺陷来指导质量内建过程，是我们需要考虑的，也就是缺陷管理的内容。本文以某实际项目的缺陷管理为例，结合自己的所思所想，讲述缺陷的记录、流转和分析。
1. 缺陷记录
1.1 哪些缺陷该被记录？
在记录缺陷前，我们要理清楚需要记录的缺陷有哪些，是不是每一个缺陷都应该被记录。一般来讲，缺陷分为两类：一类是迭代内缺陷，即在迭代新功能开发时，故事验收或测试阶段发生的缺陷；另一类则是生产缺陷，我们是允许生产缺陷的存在的，但前提是缺陷影响范围可控，或者可以在用户发现前发现缺陷（测试右移），并且要具备快速修复或者回滚的能力。
对于迭代内缺陷，一般发现阶段分为故事卡验收阶段，功能测试阶段，回归测试阶段。对于故事卡验收阶段发现的缺陷，是否需要记录可视情况而定，一般而言不需要记录，因为此时故事卡仍在开发阶段，开发同学仍然工作在这张卡上，上下文充足，修复缺陷成本较低，可以直接备注在卡片上，等下一次故事卡验收的时候再验证是否修复。对于测试阶段和回归测试阶段的缺陷，建议记录下来，因为此时开发这张卡片功能的开发同学已工作在其他卡片上，没有办法及时修复该缺陷，或者修复该缺陷的或许是其他开发人员，那么就需要将缺陷记录下来便于跟踪。
对于生产缺陷，每一个都应该被重视并且深入分析，故需要记录下来。
1.2 记录工具
在选择缺陷记录工具的时候，要考虑以下几点：
（1）该工具是否支持协同工作？
缺陷和故事卡一样重要，是各个角色都需要关心的事情，即意味着各个角色都需要能够查看、操作缺陷记录工具，所以缺陷记录工具需要支持协同工作。
（2）该工具是否容易学习？
基于第一点，团队成员均需要操作该工具，不管是否有技术背景，所以需要一个学习成本低的工具。
（3）该工具是否易于跟踪缺陷状态？
缺陷和故事卡一样存在流转状态，也会有不同的人员工作在该缺陷上（开发人员、测试人员），所以记录工具最好具有状态流转标识，当然你也可以手动记录其状态，但能让工具帮你做的事情为什么不利用工具呢？
（4）该工具是否能清晰记录缺陷？
下一小节会讲到缺陷记录的要素，选择的工具需要能清晰表达这些要素。
（5）该工具是否便于统计分析？
缺陷管理中很重要的一部分是缺陷分析，缺陷分析当然是基于数据的，这些数据可以手动收集，如果工具能自动帮你做一些统计那是最好的。
所选择的工具不一定需要具备以上提到的所有特征，但是支持协同工作、易于跟踪缺陷状态和清晰记录缺陷是必不可少的，其余特征可根据项目情况而定。我所在的项目选择的记录工具是看板，是项目基于Jira定制化开发的一个协同办公系统，在这里我们可以将其视为和Jira无异。我们在故事卡的泳道下面新建了一个跟踪缺陷卡的泳道，一个缺陷记录一张卡片，这样大家就可以像操作故事卡一样操作缺陷卡。它支持添加自定义标签的，标注卡片优先级，添加附件，充分满足缺陷关联的内容。也支持导出卡片数据，对之后的缺陷分析十分有帮助。