bug管理一直测试工作的核心之一，所以对于整个项目来说bug管理是非常关键的一环，那么该如何使用更有效的进行bug管理呢？
经过多年的测试实践，我觉得在大多数情况下bug管理应该用轻管理。所谓的轻管理其实就是简化bug的描述和bug流转的步骤，虽然从正规的流程中来看这样会存在很多弊端，但凡事总归有好有坏，就看如何权衡其中的利弊了。
我认为是利大于弊的，原因有以下2点：
1、测试人员花费大量的时间在描述bug上了，包括预置条件，操作步骤，预期结果，实际结果等等，甚至还有附件或者截图，最后还要自己读几遍看看有没有错别字或者表达的歧义。而最后开发人员也未必会仔细看，甚至还是会产生不理解或者错误的理解，于是这些时间付出和收益并没有成正比，看似忙的很辛苦，但实际却有很多无用功。
2、还有一点就在于现在的项目都是频繁迭代，很多项目都开始使用敏捷开发，用过去的重管理模式会拖慢整个项目的进度。有时候描述一个bug的时间开发都能把bug修复了，而且这样就占据了很多实际测试的时间，本来测试时间就非常不够，还执着于bug管理就是本末倒置了，最后要不就是加班，要不就是测试不完全就上线。
当然也不是说轻模式就有多好，但从各种实践来看，bug管理只是一种手段，而非目的。而对于测试来说最宝贵的是测试时间，让测试和开发能够同时工作，而不是测试在bug管理上花费时间的时候，开发没有事情做。原因其实已经分析差不多了，那么实际上如何减少在bug上花费时间呢?
我觉得有以下几点建议：
1、太过于复杂和很难描述清楚的bug可以叫开发人员过来看，如果条件不允许的话可远程演示或者录屏保存发送，当然bug还是要记录的，只是记录一个大概问题，不必太详细描述，只需要自己心里知道bug如何重新和如何验证就可以了。（注意时机，频繁这样会打断开发思路）
2、还有些bug可以通过截图描述的，就不要用文字表达（有图有真相，IT人都知道），截图然后圈一下问题点简单加上文字描述，然后放到bug管理工具的附件之中，开发看一眼应该基本可以明白是什么问题了，毕竟这样比单纯看文字直观多了。
3、当然如果能力允许，可以定位到bug的原因（即哪个代码判断有问题或者计算不对等等），然后直接描述bug点在哪里，一方面言简意赅的表述了bug，一方面也方便了开发定位和解决问题。（定位bug的技能大家一定要get）
4、除了bug描述上可以从简，其实从bug的流转上也可以“偷懒”。一般提交bug到开发这边，开发往往会解决了问题而不把bug状态改成fix状态，于是要催开发改状态，改完之后发现bug还没修复，于是又把状态改成reopen重新发给开发人员，然后开发改完又要催他改状态。周而复始几次就耗费大量时间，除了记录bug的状态不停更新，并没有什么实际用处，而对于bug管理目的只有2个，记录bug和最后bug被修复验证通过，因此其实只需要等bug验证通过后closed，中间那些流转过程则可以选择性的“省略”（谨慎使用，很多时候这些流转信息是很有必要的，有助于进行质量过程控制和改进）。
最终目的就是不要被bug管理束缚，解决问题才是关键。用bug的轻管理能让测试人员从其中解放出来，从而投入到真正需要花时间测试的地方，无论从测试人员本身或者项目的进度上来说都是利大于弊的，我想这也是未来测试的趋势吧