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

既然无法完全阻止缺陷的出现，那如何确保已发生的缺陷得到有效的处理，如何利用已有缺陷来指导质量内建过程，是我们需要考虑的，也就是缺陷管理的内容。

敏捷测试原则中有一条是：预防缺陷，而不是关注缺陷的数量。在敏捷开发中，虽然我们采取了各种措施预防缺陷的发生，例如精准的自动化测试、代码检视、故事卡验收等等，但是并不能保证没有缺陷发生，一个零缺陷的产品也不现实。既然无法完全阻止缺陷的出现，那如何确保已发生的缺陷得到有效的处理，如何利用已有缺陷来指导质量内建过程，是我们需要考虑的，也就是缺陷管理的内容。本文以某实际项目的缺陷管理为例，结合自己的所思所想，讲述缺陷的记录、流转和分析。

1. 缺陷记录

1.1 哪些缺陷该被记录？

在记录缺陷前，我们要理清楚需要记录的缺陷有哪些，是不是每一个缺陷都应该被记录。一般来讲，缺陷分为两类：一类是迭代内缺陷，即在迭代新功能开发时，故事验收或测试阶段发生的缺陷；另一类则是生产缺陷，我们是允许生产缺陷的存在的，但前提是缺陷影响范围可控，或者可以在用户发现前发现缺陷（测试右移），并且要具备快速修复或者回滚的能力。

对于迭代内缺陷，一般发现阶段分为故事卡验收阶段，功能测试阶段，回归测试阶段。对于故事卡验收阶段发现的缺陷，是否需要记录可视情况而定，一般而言不需要记录，因为此时故事卡仍在开发阶段，开发同学仍然工作在这张卡上，上下文充足，修复缺陷成本较低，可以直接备注在卡片上，等下一次故事卡验收的时候再验证是否修复。对于测试阶段和回归测试阶段的缺陷，建议记录下来，因为此时开发这张卡片功能的开发同学已工作在其他卡片上，没有办法及时修复该缺陷，或者修复该缺陷的或许是其他开发人员，那么就需要将缺陷记录下来便于跟踪。

对于生产缺陷，每一个都应该被重视并且深入分析，故需要记录下来。

1.2 记录工具

在选择缺陷记录工具的时候，要考虑以下几点：

（1）该工具是否支持协同工作？

缺陷和故事卡一样重要，是各个角色都需要关心的事情，即意味着各个角色都需要能够查看、操作缺陷记录工具，所以缺陷记录工具需要支持协同工作。

（2）该工具是否容易学习？

基于第一点，团队成员均需要操作该工具，不管是否有技术背景，所以需要一个学习成本低的工具。

（3）该工具是否易于跟踪缺陷状态