使用Bugfree不应有的坏习惯

使用Bugfree不应有的坏习惯

　Bugfree是一款优秀的 bug管理和追踪工具，因此受到不少公司的青睐。但实际的 工作中，我发现不少开发或是 测试的同事有一些不好的使用习惯，使得我们对Bugfree的利用不够高效。我下面列出使用Bugfree的一些坏习惯，以此与各位测试同仁切磋使用这个工具的高效的方法。

　　对开发的同事而言，可能会有下面几条坏习惯。

　　 坏习惯一：只采用默认的解决方案。

　　周围不少开发的同事，在解决掉一个bug的时候，往往只采用默认的解决方案：fixed。事实上，Bugfree提供了7种解决bug的方案供程序员选择。它们分别是：By Design、Duplicate、External、Fixed、Not Repro 、Postponed、Won't Fix 。这7种解决方案反应了程序员解决bug的理由。By Design的意思是，设计上就是这么定的，bug无效；Duplicate的意思是，这个bug已经有人提过，重复了；External的意思是，软件本身没有问题，是外部因素（比如 操作系统）造成的问题；Fixed的意思是：bug被解决掉了；Not Repro的意思是，这个bug无法重现；Postponed的意思是，这个bug推迟到以后解决；Won't Fix的意思是，是个问题，但是不值得解决。为什么会有这种习惯呢？我询问过一位开发的同事，他说看不懂英文，又懒得去查。另一位开发同事说，一开始没注意到这一项是可选的，时间久了，自然而然就视而不见了。

　　改掉这个习惯不是更好吗？我的理由：给bug设置正确的解决方案，一方面可以减少开发和测试的沟通障碍，让测试员知道程序员为什么要关掉这个bug；另一方面可以给bug归类，便于查找bug和开发后期集中解决bug。

　　 坏习惯二：只在详细信息里写上：已解决。

　　由Bugfree提供的7种解决方案，不难看出详细信息这一栏多数情况下是为第四种解决方案Fixed提供补充的。很多bug在被fixed掉以后，如果只在这一栏注明已解决字样会有不好的影响。因为时间久了，或许程序员自己都不清楚这个bug是怎么被fixed掉的，如果再碰到类似的问题又要花很长时间去想办法解决，影响工作的效率。

　　改掉这个习惯不是更好吗？我的理由：在详细信息栏里注明bug被fixed掉的理由，一方面像上面所说的可以给开发人员提个醒，便于解决类似的bug；另一方面对测试员也有好处。测试员在碰到类似的bug以后，能够知道哪儿出了问题，这样就可以准确及时地提醒开发人员，便于bug的修改。

　　对测试的同事而言，可能会有下面的几条坏习惯。

　　 坏习惯一：创建bug时，选错了项目。

　　周围有测试同事，在发现了bug后，就急急忙忙去bugfree里描述bug和指派bug，往往会忽略其他的选项。就拿这个项目来说，登录bugfree后里面就有默认的内容，但未必是和bug相对应的。如果测试人员因为发现了bug，有点兴奋，再加上一点粗心就会忽略这一项。

　　改掉这个习惯不是更好吗？我的理由：设置正确的项目可以给bug归类，便于bug的查找。若选错了项目，难免会抱怨找不到自己创建的bug，还得通过其他方式查找这个沉入“大海”的bug，影响了工作的 心情和效率。

　 　坏习惯二：创建bug时，没有选/选错了模块。

　　创建bug时，模块这个选填项，不仅看起来不起眼，而且会让人误以为它没有用，所以测试人员往往会忽略它。         改掉这个习惯不是更好吗？我的理由：设置正确的模块，可以给bug分门别类。这样，开发人员就能很方便知道A模块有哪些bug，B模块有哪些bug，让开发人员对自己负责的项目模块心里有底。所以，还请测试人员辛苦下，把模块这一项设置好。

　 　坏习惯三：设置错误的严重等级。

　　周围有同事，往往只注重对bug地描述，不去关注对bug等级的设置，不利于开发人员优先解决严重的bug。其实Bugfree提供可选的4种严重等级：1、2、3、4。1是最高等级，意思是这个bug导致系统死机，数据丢失或者与需求不符合；2是严重等级，意思是这个bug导致计算出现错误，功能实现出现错误；3是一般等级，意思是这个bug是个合法性问题，界面问题或是文档问题等；4是最低等级，意思是这个bug影响易用性。不少情况下是测试人员不清楚各种级别的含义，导致的分类错误。

　 　改掉这个习惯不是更好吗？

　　我的理由：设置正确的严重等级，可以让开发人员优先解决1、2bug，在项目时间允许的情况下，再着手解决3、4类bug，以保证产品的质量。啰嗦一句，首先要保证产品能用，再去保证产品好用。

　　其实最好的习惯是按照bugfree的格式，把每一项该填的内容填好！！