BUG的流动
　　可能会在不同角色间流动，比方分配给某个开发的BUG，他通过了解发现BUG描述不清楚无法开始工作，他会把BUG重新分配给测试人员。也有可能测试发现开发并没有解决问题，把BUG再转给开发。我认为，正常的流动是必须的，特别是大型系统中，各个开发团队负责一部分内容，所以要果断将不属于自己能力范围内的bug及时转给对的开发人员；也有可能，问题的表象是发生在了客户端，比方字段的显示不对，但根源是在服务器端。那么开发人员必须留下必要的备注说明自己分析的内容，然后及时转给对应的负责人。特别忌讳的是不健康的流动，不加上自己的分析备注转给他人（不说明来意），或者对测试提的bug吹毛求疵，粗鲁对待。记得，bug系统的存在是为了提高协作效率，不要推诿责任，必要的时候可以直接走到别人的座位上，问清楚原因。
　　我们提倡有益而又健康的流动，拒绝无谓的，纯粹推诿的流动。
　　终结一个BUG
　　除了确实是bug，且被解决了这个happy ending，bug还有其他可能的命运；
　　1，确实是个bug，但是影响很小，而且修复工作量巨大，导致影响到其他模块，所以不予修复；
　　2，需求未能定义清楚，导致测试和开发的理解有不同，需要明确需求；
　　3，是个问题，但有BUG提到了同样的bug，所以需要合并处理；
　　4，是个bug，但在本次版本中不予修复；
　　5，是个bug，但始终不能复现，开发人员长时间无法进行调研，所以暂时关闭；
　　... 总结来说，不是所有的BUG都是BUG，不是所有的BUG都必须解决。
　　谁是BUG系统的负责人
　　俗话说一山难容二虎，也是说一件事只能有一个负责人；那么谁是BUG系统的负责人？我认为，测试人员应该是BUG系统当仁不让的负责人，BUG系统是测试人员的主战场：
　　1，保证录入的bug质量，检查每个bug描述是否完整准确；
　　2，以及检查开发人员解决bug的备注是否完整，解释又是否合理；如果解释不合理，必须要求开发人员重新填写。
　　3，保证每次发现的问题及时录入到系统中，建议测试过程中发现的问题截图收集完日志后，简单用笔记录下。全部完成测试后再一次性记录到BUG系统中。
　　4，追踪BUG修复的情况：BUG是否在修复中了；及时测试已被修复BUG。
　　BUG系统的其他重要作用
　　需求变更库：很多公司不但把BUG系统也称作为需求变更管理库，这意味着不但可以录入bug，有些小功能，小需求，小的用户体验改进也可录入。我非常推荐这种做法。
　　测试用例库：像禅道可以记录测试用例子；我觉得测试核心的能力之一在于设计测试用例的能力，具体测试的过程，只是一个按测试用例执行的过程。禅道里可以在项目进入开发阶段时，开始设计并录入测试用例。而且还可以把发现的某个bug转变为一个测试用例。
　　与版本管理相关联：一个bug的解决意味着代码的提交，所以可将bug管理系统和版本管理系统相结合和关联。如，clearquest与clearcase关联，禅道和svn关联（注：收费功能，我没用过 呵呵）。
　　经验教训库：这里的每个内容都是一个你犯过的错误，你在这里也记录的总结和反思；随着系统开发不断往前迭代，BUG的内容也会越来越丰富，沉淀了越来越多的经验，帮助我们了解错误原因所在，避免再犯。
　　当前流行的BUG管理系统
　　大公司会使用clearquest，IBM rational出品，适合管理超大型项目。简单项目管理有bugfree，国产的禅道，都是开源的，下载下来后自己安装。还有一些系统无需安装，只要申请账号既可以直接使用，具体笔者没有自己使用过，需要大家自己去找一下。
　　必要要说的是，一个团队要强大起来，先从自己的BUG系统开始做起。