为了不逼疯产品经理，我们建立了一个缺陷管理（1）

lsekfe

一个有效的缺陷管理流程有多重要？我见过一些团队并没有一套有效的流程，而是通过口头或者邮件的方式进行着缺陷管理，这些方式可能会导致许多问题，比如：
　　测试人员和产品经理说：我们发现了15个Bug。产品经理提交给开发人员了过会儿，开发人员说：我修复了14个，另一个不是Bug。
　　产品经理当然就又要提交给测试人员啦~
　　然后，测试人员说：有1个Bug没有修复，另外我又发现了9个新Bug。
　　产品经理此时内心是一万只神兽奔腾。
　　看得明白吗？看不明白……看不明白就对了！如果没有一个有效的缺陷管理，就仅仅是这样口头进行沟通，很快事情就复杂到谁也看不明白了，然后很快产品经理就疯了……
　　所以，如果身为产品经理你不想要疯掉，那你就需要学会建立一套有效的缺陷管理。
　　那么今天笔者就通过项目管理平台——CORNERSTONE，为大家演示如何建立一套有效的缺陷管理。
　　缺陷管理的流程

（1）准备工作：
　　创建测试用例
　　一个有效的缺陷管理，首先，测试人员当然不能是像上文那套场景中，想到哪儿测到哪儿，那咱这产品上线是指望不上了……所以在第一步，我们要进入测试用例页面，创建测试用例。
　　在CORNERSTONE中，企业可根据产品特性自定义用例模版，并补充优先级/状态/责任人、添加描述、评论等操作，可以说是相当的灵活方便。

创建测试计划
　　有了用例，这还只是知道了测试人员要测什么，接下来怎么测还得明确一下，因此要创建测试计划。
　　测试计划是描述要进行的测试活动的范围、方法、资源和进度的文档。是对整个信息系统应用软件组装测试和确认测试。它能够确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。
　　通过CORNERSTONE，用户可以在测试计划中对责任人、优先级、状态、分类、迭代、截止时间等属性进行初始设置。

创建完成后，我们可以关联编写好的测试用例，方便测试人员操作。
　　记得曾经听位老产品经理吐槽，说测试人员写个项目的测试用例能有《莎士比亚全集》那么厚。可见测试用例多难写……不过好在我们现在可以借助一些工具，比如说CORNERSTONE里提供的测试与缺陷管理模块，就支持将思维导图一键生成测试用例，这样的设计可以说是相当省心了~

（2）发现缺陷
　　万事俱备，那么测试人员就可以开始测试了，测试人员根据CORNERSTONE的测试计划页中的内容进行测试，测试不通过，发现缺陷啦，快去缺陷页创建一个缺陷吧……哪有那么麻烦！在CORNERSTONE中，我们可以把测试用例关联到缺陷中，只要直接把测试状态为“不通过”，缺陷就会自动更新状态。下图是一个比较常见的缺陷状态流转图：

未解决
　　缺陷显示为未解决状态，测试人员要将缺陷通过设置“责任人”，交给对应的负责人，对应的责任人将收到来自CORNERSTONE的缺陷变更通知，得~有得忙了……
　　拒绝
　　在CORNERSTONE里，同样也支持所有成员修改缺陷状态，因为有时候开发人员会认为提交上来的缺陷并不是真正的缺陷，比如由于缓存问题、网络问题等，应将缺陷状态标记为“拒绝”，并附上说明，此时测试团队需要重新测试或者提供更多的缺陷信息。
　　补充：使用CORNERSTONE的用户可自定义缺陷的流转过程的。

Miss_love