bug处理流程

bug处理规则。

1、每一个bug，开发在修复（fixed）或者拒绝（rejected）后，都需要给出一个注释，添加注释之前，需先点一下“添加注释”的按钮，如下图所示，这样添加注释人员的名字就会出现，否则，添加注释的人多了，不知道是谁写的。具体注释的内容（产生bug原因，修改的地方）是由各个组自己跟开发约定。

2、在bug处理过程中，如果一个bug开发方认为

a、当前不能做，或者需要延迟开发；

b、就应该是这样的，不是bug

遇到这两种情况时，bug状态可以改为rejected，同时需**（assigned&to）该bug给项目经理进行确认，项目经理需要对此bug做一个说明（加一个注释），测试人员根据项目经理的解释决定这个bug的最终状态。

3、bug状态的转换：以下几类问题不可以被rejected回来，一旦发现开发把下列问题rejected回来，我们不可以直接closed掉，要根据实际情况做出reopen或deferred处理。

1)、环境配置问题

2)、数据问题

3)、历史问题

4)、需求问题

只有因为我们理解的偏差导致的不需要任何修改，客观上本来就是正确的bug才可以直接closed掉。

4、comment问题：除open和closed两种状态可以不加注释外，其它任何的状态改变都要加上注释说明。

5、deferred问题处理：测试人员需评估deferred的风险，线下跟项目经理和项目测试负责人（或是导师）review。

a)几方讨论都同意deferred：qa应把bug指派给项目经理，项目经理在“comment”中加上注释，对此bug的处理解决方案；然后ｑa把此bug为deferred状态，并说明。

b)几方讨论不同意deferred此bug：ｑａ需reopen此bug给开发人员。

c)小需求中的bug要deferred，流程和处理方式同项目deferred处理。

d）项目结项后，项目组需要在2周内完成项目deferred&bug的修复计划，并按照计划进行修复；如果未能按照计划修复的deferred&bug按照deferred&bug处理流程处理。

6、bug的生命周期，适时结束：当前问题解决后，适时将bug&closed掉。由于当前这个bug引起的其它问题，另设bug去跟踪。

closed的bug原则上不允许再reopen出来。

7、开发在处理不了当前bug或认为该bug非自己所有时，可转给对应的开发或开发技术经理assigned&to，但不能变更该bug状态。由相应开发或技术经理去处理这个bug。

8、关于bug指派问题

1）由于项目或小需求导致的bug&deferred的话直接指派给相应开发人员

2）如果是历史遗留问题可以找相应产品线的开发主管商量指派给谁

3)如果是需求有问题，开发已经开发了，我们跟需求确认是需求问题，我们把bug提给需求编写者，如果需求文档已经更新了（并通知了相关人员），该bug还是提给开发人员。