一个有效的缺陷管理流程有多重要？我见过一些团队并没有一套有效的流程，而是通过口头或者邮件的方式进行着缺陷管理，这些方式可能会导致许多问题，比如：
测试人员和产品经理说：我们发现了15个Bug。 产品经理提交给开发人员了 过会儿，开发人员说：我修复了14个，另一个不是Bug。 产品经理当然就又要提交给测试人员啦~ 然后，测试人员说：有1个Bug没有修复，另外我又发现了9个新Bug。 产品经理此时内心是一万只神兽奔腾。
所以，如果身为产品经理你不想要疯掉，那你就需要学会建立一套有效的缺陷管理。
那么今天笔者就通过项目管理平台——CORNERSTONE，为大家演示如何建立一套有效的缺陷管理。
缺陷管理的流程
创建测试用例
一个有效的缺陷管理，首先，测试人员当然不能是像上文那套场景中，想到哪儿测到哪儿，那咱这产品上线是指望不上了……所以在第一步，我们要进入测试用例页面，创建测试用例。
在CORNERSTONE中，企业可根据产品特性自定义用例模版，并补充优先级/状态/责任人、添加描述、评论等操作，可以说是相当的灵活方便。
有了用例，这还只是知道了测试人员要测什么，接下来怎么测还得明确一下，因此要创建测试计划。
测试计划是描述要进行的测试活动的范围、方法、资源和进度的文档。是对整个信息系统应用软件组装测试和确认测试。它能够确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。
通过CORNERSTONE，用户可以在测试计划中对责任人、优先级、状态、分类、迭代、截止时间等属性进行初始设置。
记得曾经听位老产品经理吐槽，说测试人员写个项目的测试用例能有《莎士比亚全集》那么厚。可见测试用例多难写……不过好在我们现在可以借助一些工具，比如说CORNERSTONE里提供的测试与缺陷管理模块，就支持将思维导图一键生成测试用例，这样的设计可以说是相当省心了~
（2）发现缺陷
万事俱备，那么测试人员就可以开始测试了，测试人员根据CORNERSTONE的测试计划页中的内容进行测试，测试不通过，发现缺陷啦，快去缺陷页创建一个缺陷吧……哪有那么麻烦！在CORNERSTONE中，我们可以把测试用例关联到缺陷中，只要直接把测试状态为“不通过”，缺陷就会自动更新状态。下图是一个比较常见的缺陷状态流转图：
缺陷显示为未解决状态，测试人员要将缺陷通过设置“责任人”，交给对应的负责人，对应的责任人将收到来自CORNERSTONE的缺陷变更通知，得~有得忙了……
拒绝
在CORNERSTONE里，同样也支持所有成员修改缺陷状态，因为有时候开发人员会认为提交上来的缺陷并不是真正的缺陷，比如由于缓存问题、网络问题等，应将缺陷状态标记为“拒绝”，并附上说明，此时测试团队需要重新测试或者提供更多的缺陷信息。
补充：使用CORNERSTONE的用户可自定义缺陷的流转过程的。
比如：
l 如果开发团队收到的缺陷是重复的，或者与其他正在进行中的缺陷问题相似，可以标注为“重复”。
l 对于部分不紧急的缺陷问题，比方说可能会随着日后的产品迭代中进行修复，对于这类缺陷可以标注为“延期”。
待测试
当开发团队修复缺陷后，应将缺陷状态标记为“待测试”，交给测试人员再次进行测试。测试不通过，测试人员再次将状态更改为未解决，并添加说明。
关闭
在测试通过后，缺陷状态修改为“关闭”或者完成。
你看，缺陷管理这样来走，什么“还剩一个是不是Bug”的，在走流程的过程中已经得到处理了。
设置合理的缺陷处理优先级 刚才在讲解流程的时候我们提到一个关键词“优先级”。我们都知道，软件产品就中的缺陷是难以避免。 这些缺陷有轻有重，有一些缺陷如果没有得到及时和有效的解决，可能会造成非常严重后果，而另一些轻微的缺陷，即便没有修复几乎所有人都不会注意到。
对于这些缺陷，我们真心没必要去浪费时间，除非你有无限的资源来分配好所有的缺陷修复任务，否则你需要优先将资源集中投资回报的缺陷修复上。
制定一套缺陷处理准则 要高效的处理缺陷问题，就需要建立流程，要建立流程，就需要有制定一套团队间通用的缺陷处理准则。这样，我们不用再对每一个缺陷问题进行详细的评估，而是可以直接按照我们制定的准则，通过管理工具快速处理。
下面这一套缺陷等级准则范例，大家可以参考，并依据自身的实际情况来设置自己的等级标准。
l 低：无关紧要的问题或某些功能不可用，但有一个简单的解决方法
l 中：辅助功能不可用，但有合理的解决方法
l 高：重要功能不可用，但有一个合理的解决方法
l 严重：数据丢失、数据损坏或系统不可用
严重：必须立即处理，插入到当前的产品迭代版本中，高于其他需求开发。
高：快速处理，插入到当前的产品迭代中，但是低于部分本次迭代需求开发任务。
中：处理，可以随着下一次产品迭代进行处理。
低：选择性处理，根据迭代进度可放入下次迭代或者下几次迭代中进行处理。
这种方法的关键优势在于，它大大减少了用于讨论如何处理每一个缺陷的时间。另外，团队考虑的两个因素影响范围和严重程度是相对客观的，减少了我们由于主观因素带来的误差，让衡量标准更容易判断，也就可以更简单和高效的制度缺陷处理优先级别。
关于如何建立一个缺陷管理，就和大家分享到这儿。
最后不得不说，众多缺陷处理完成后团队需要有数据支撑，以及时的发现问题，解决问题，改进缺陷管理流程。同时，可以很好的衡量团队工作成果，工作进度，检测产品各个模块的缺陷变化趋势等。因此，一款好的缺陷管理工具应该有多种维度的数据报告能全局查看修复情况，有效预防风险。
全行业覆盖的一站式项目协作平台
官网链接，收好不谢！
