关于BUG管理(乱七八糟节选版) 来自http://bugfree.1zsoft.com/

原始版本
http://bugfree.tigris.org/files/documents/2728/23338/Bug1.pdf
http://bugfree.tigris.org/files/documents/2728/23339/Bug2.pdf
http://bugfree.tigris.org/files/documents/2728/23340/Bug3.pdf

以下是我精简的.原文版权归作者所有,我只是节选了一部分.

    研发人员分工明确。主要的三个角色：PM (Program Manager)、Dev (Developer)、Tester三者分工明确、接口清晰，PM 来定义需求、书写出来每个功能特性(Feature)的设计文档(Spec)，Dev 写代码来实现这个Spec，Tester 来测试Dev 做出来的东西是否符合PM 定义的Spec，三个角色之间并无必然的上下级关系，只是分工合作完成某个功能(Feature)。

    开发人员写出设计文档，然后动手写代码；测试人员理解需求文档，然后测试做出来的功能是否符合最初的设想。整个过程碰到的任何问题都要通过Bug 系统来记录、跟踪，相关人员通过Bug 管理来商谈、沟通相应的解决方案。这样通过Bug 管理，逐步统一研发人员的思维、做事模式，让整个团队可以有效地运转起来，并不断优化自己项目的软件研发流程，提高产品质量，从而使产品可持续发展。

 

    在整个产品的研发过程中，特别是在测试产品、修复Bug 的中后期，团队中所有人都生活在Bug 中：

- 测试人员（Tester）只要发现问题就立即新建一个Bug 予以跟踪并指派给相关的开发小组长（Dev Lead）

- 开发小组长会判断这个Bug 属于某个特定的开发人员（Dev）并指派给他处理

- 开发人员会根据Bug 的详细描述信息找到问题所在，修改程序解决这个Bug 并把Bug返回给当初的测试人员；或者有争议的时候，把Bug 指派给这个Feature 的定义者PM，要求一个澄清说明

- 测试人员在看到某个Bug 被解决后，就去验证这个Bug 是否真的不存在了，根据最初的发现步骤去证实问题真的解决了就关闭这个Bug；若还能重现，或者不同意开发人员的解法，可以激活这个Bug，返还给当初的开发人员做进一步调查处理

- 当测试人员和开发人员无法达成一致意见的时候，由对应的PM 出面做协调，判断这个Bug 的严重程度、对用户可能的影响，根据产品的进度和项目资源做出评估，是否真的需要修理掉这个问题

 

       Bug的一生：如何发现（创建Bug）、不断讨论（编辑Bug）、找到原因（解决Bug）到最后关闭它。