敏捷项目如何进行缺陷管理

1 引言

敏捷测试原则中有一条是：预防缺陷，而不是关注缺陷的数量。敏捷团队中是整个团队为质量负责，团队追求的是整个产品质量的提升，而非传统的开发人员追求零缺陷，测试人员追求找到更多的缺陷。在敏捷开发中，虽然我们采取各种措施预防缺陷的发生，例如精准的自动化测试、代码检视、故事卡验收等等，但是并不能保证没有缺陷发生，一个零缺陷的产品也不现实。既然无法完全阻止缺陷的出现，那如何管理发生的缺陷，如何利用已有缺陷来指导质量内建过程，是我们需要考虑的。

本文以博主在实际项目中的经验，讲述缺陷的记录、流转和分析，每个模块的内容会分别讲述迭代内缺陷和生产缺陷的管理。

2 缺陷记录

2.1 哪些缺陷该被记录？

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

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

2.2 工具

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

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