【转】bug管理-易简不易繁

【要有快速解决问题的想法】

bug管理一直测试工作的核心之一,所以对于整个项目来说bug管理是非常关键的一环,那么该如何使用更有效的进行bug管理呢?

经过多年的测试实践,我觉得在大多数情况下bug管理应该用轻管理。所谓的轻管理其实就是简化bug的描述和bug流转的步骤,虽然从正规的流程中来看这样会存在很多弊端,但凡事总归有好有坏,就看如何权衡其中的利弊了。

我认为是利大于弊的,原因有以下2点:

测试人员花费大量的时间在描述bug上了,包括预置条件,操作步骤,预期结果,实际结果等等,甚至还有附件或者截图,最后还要自己读几遍看看有没有错别字或者表达的歧义。而最后开发人员也未必会仔细看,甚至还是会产生不理解或者错误的理解,于是这些时间付出和收益并没有成正比,看似忙的很辛苦,但实际却有很多无用功。
【转】bug管理-易简不易繁_第1张图片
image.png

还有一点就在于现在的项目都是频繁迭代,很多项目都开始使用敏捷开发,用过去的重管理模式会拖慢整个项目的进度。有时候描述一个bug的时间开发都能把bug修复了,而且这样就占据了很多实际测试的时间,本来测试时间就非常不够,还执着于bug管理就是本末倒置了,最后要不就是加班,要不就是测试不完全就上线。

当然也不是说轻模式就有多好,但从各种实践来看,bug管理只是一种手段,而非目的。而对于测试来说最宝贵的是测试时间,让测试和开发能够同时工作,而不是测试在bug管理上花费时间的时候,开发没有事情做。原因其实已经分析差不多了,那么实际上如何减少在bug上花费时间呢?

我觉得有以下几点建议:

太过于复杂和很难描述清楚的bug可以叫开发人员过来看,如果条件不允许的话可远程演示或者录屏保存发送,当然bug还是要记录的,只是记录一个大概问题,不必太详细描述,只需要自己心里知道bug如何重新和如何验证就可以了。

还有些bug可以通过截图描述的,就不要用文字表达,截图然后圈一下问题点,然后放到bug管理工具的附件之中,开发看一眼应该基本可以明白是什么问题了,毕竟这样比看文字直观多了。
【转】bug管理-易简不易繁_第2张图片
image.png

当然如果能力允许,可以定位到bug的原因(即哪个代码判断有问题或者计算不对等等),然后直接描述bug点在哪里,一方面言简意赅的表述了bug,一方面也方便了开发定位和解决问题。
【转】bug管理-易简不易繁_第3张图片
image.png

除了bug描述上可以从简,其实从bug的流转上也可以“偷懒”。一般提交bug到开发这边,开发往往会解决了问题而不把bug状态改成fix状态,于是要催开发改状态,改完之后发现bug还没修复,于是又把状态改成reopen重新发给开发人员,然后开发改完又要催他改状态。周而复始几次就耗费大量时间,除了记录bug的状态不停更新,并没有什么实际用处,而对于bug管理目的只有2个,记录bug和最后bug被修复验证通过,因此其实只需要等bug验证通过后closed,中间那些流转过程则可以选择性的“省略”。

最终目的就是不要被bug管理束缚,解决问题才是关键。

用bug的轻管理能让测试人员从其中解放出来,从而投入到真正需要花时间测试的地方,无论从测试人员本身或者项目的进度上来说都是利大于弊的,我想这也是未来测试的趋势吧。

你可能感兴趣的:(【转】bug管理-易简不易繁)