一个新项目的开始，往往需要定义该项目中对于Bug的管理流程。下面简单介绍一个基于VSTS 2010工具的Bug流程管理定义，希望起到抛砖引玉的作用。

　　一、Bug的生命周期

　　Bug的流程管理首先需要定义一个Bug的产生到终结这个过程的所有状态及相应动作。下图是Bug的生命周期示意图，对Bug的产生与动作进行了定义：

　　黄色方框描述的是Bug的状态，从图中可以看出一个Bug只有三个状态：活跃的（Active）、解决的（Resolved）和关闭的（Closed）。绿色的终结状态是关闭后的自然产生状态，无需操作。蓝色方框表示的是在开发人员和测试人员对某个Bug观点不能达成一致时的处理方式，即召开Bug讨论会（Bug-scrub meeting），参会人员应该包括：开发工程师（经理）、测试工程师（经理）、项目经理、产品经理以及售前与售后工程师。简言之，尽可能多地包括产品涉众。

　　Bug的提交有两种情况：

　　1.测试人员执行测试用例发现了Bug。

　　2.构建产品过程中失败，持续构建系统自动提交Bug。在对这个失败进行分析后，可以给予更详细的更新。

　　Bug的解决有两条路径：

　　I.DEV直接解决。这里面包括四种原因

　　1）.问题修复了（Fixed），文档或者程序进行了修改；
　　2）.重复的Bug（Duplicate），之前有过同一现象报告，或者同一根本原因（Root Cause）；
　　3）.无法重现（Cannot Reproduce）；
　　4）.废弃的（Obsolete），Bug所在模块被去除。

　　II.DEV和Tester对某个Bug不能达成一致，比方说DEV认为是应有的行为，虽然需求文档没有定义，而Tester认为行为会影响用户体验。这时Dev可以把Bug所有人改为项目经理便于召开Bug-scrub meeting进行讨论。涉众们共同讨论确定对Bug的处理意见:

　　1）.不修复，同意是个Bug，但基于人力，时间或者对产品重新引入的风险考虑而选择放弃修复。
　　2）.不是Bug，涉众们讨论认为行为满足了用户需求，不是Bug，或者Tester发生误报（会前如果Tester认同，不需将此Bug列为讨论范围，由Tester自行关闭）。
　　3）.是Bug，而且需要得到解决。

　　对于一个解决了的Bug，Tester需要对其进行验证。两种情况可能发生：

　　1.Bug得到修复，Tester对其进行关闭

　　2.Bug没有得到修复，Tester重新将Bug改为活跃状态，Bug持有人改为DEV。

　　关闭的Bug可能在之后的某次测试重新发现或者经过分析发现仍会存在，将该关闭的Bug重新改回活跃状态报给相应DEV。

　　注：这些状态和原因可以在VSTS中进行定制，不过需要安装TFS的Power Tools。