好的bug管理应该有哪些流程？

好的bug管理应该有哪些流程？

BUG管理人员接到BUG提交信息后首要要根据BUG严重等级分类，比如致命：造成系统死机、程序崩溃、死循环、造成系统主要功能无法实现的异常等；产品的关键功能和性能不能符合用户要求。严重：重要功能基本实现，但系统不稳定、会导致数据破坏丢失、运行错误、操作性错误、功能不能实现、功能遗漏、错误结果等。
然后根据BUG的严重等级进行分析，哪些需要优先修复，必须要尽快修复的BUG，这些BUG直接影响到产品发布进度和最重要的功能使用，这些BUG不修复，将会阻碍其他任务的完成，项目组必须组织人力，马上进行修复；如果时间允许就修正的BUG，这样的BUG一般来说不会影响里程碑版本的使用，是否需要修复根据项目组的时间和资源情况考虑，如果时间允许，就会修正；
在解决Bug的流程中，最阻碍开发同学效率的是“Bug复现”问题；当信息不完备时，开发、产品，Bug反馈者通常需要3-5个来回，来确认，在全部精力投入的情况下，平均约耗时30分钟能够确认一个Bug场景。同样，我们选择好的管理工具，可以避免这30分钟的沟通与确认时间成本。
我们团队现在直接在日事清内进行“bug管理”，提bug人员将bug输入到“收集”状态，由产品助理集中处理，视bug具体情况将bug拖拽到其他集中状态。如果拖拽到“确认”，在该bug下添加相应技术人员让其处理，技术人员会在日事清协作系统内收到通知并且bug同步到其收纳箱，方便技术人员集中处理，解决后由技术人员拖拽到“已解决”状态卡片，这样提高了bug管理效率，节约了大量的时间。

1. 测试人员提交新的bug入库，错误状态为new。 2. 高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为open。如果不是错误，则拒绝，设置为declined(拒绝)状态。 3. 开发人员查询状态为open的bug，如果不是错误，则置状态为declined；如果是bug则修复并置状态为fixed。不能解决的bug，要留下文字说明及保持bug为open状态。对于不能解决和延期解决的bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。 4. 测试人员查询状态为fixed的bug，然后验证bug是否已解决，如解决置bug的状态为closed，如没有解决置状态为reopen。 软件错误流程管理要点 为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。 每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，bug状态。 拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。 错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。 加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例