关于Bugzilla本人也在不断学习中,有经验交流请给我mail。

为什么我需要Bugzilla

一个软件写完后,事情才刚刚开始。目前我接触到的项目都是小作坊式的开发环境,所以没有专门的测试人员,开发人员就是最开始的测试人员,客户也是某种意义上的测试人员。虽然经过开发人员的测试,软件应该没有什么大的bug了,但是bug总是永远存在的,不过它有多小。而且客户的需求也是一直在改变。

在这个条条道路通我的信息时代,客户可以用电话,发qq信息,msn信息,email,或者冲过来告诉我:我中奖了,我发现一个bug,或者我想增加、修改一个功能。在这些交流方式中,我推崇用email交流,email是异步的,而且email承载的信息量比较大,Beta也说了,回email时我们一般都需要思考,不管上帝是不是在发笑,至少经过思考后,我们的答复会更周全,而不是在qq里说:我知道了。好的。

我推崇email的另一个原因是基于计算机里面的一种队列queue的概念。即时信息类似一个中断,收到这个信息你被迫停止手头的工作立刻尽快做出答复。而email你可以累计4、5封mail后一并回复,如果不是那么急的话。假设我需要完成的一系列事件都看成是一个个project时,就在今天,有一个project,负责的A客户说他希望把一个网站的首页的文字“人生如梦”改为“人生是一场梦”,对于这样的修改,最慢的修改可能需要0.1秒,但是我用cuteftp连接网站,下载index.html,用editplus打开index.html,修改,上传。总过程取决于网站速度,可能是5分钟,这样效率非常低,而且你永远不知道客户什么时候给你来这个中断,可能在你关闭editplus和cuteftp拿起咖啡的时候,客户又告诉你,他想把“人生是一场梦”改为“人生是两场梦”。人生是一场梦。

除了上面的原因,反观我以往bug追踪的过程,我手动在一个目录里维护一个todolist.txt,客户或协作人员用qq,msn,email等等告诉我,和我交流。等bug数目累计到一定程度后,我开始查找聊天记录,收集更新todolist.txt,接着开始update代码。这是石器时代的做法。

所以我需要Bugzilla。我需要一个系统,可以收集我负责的软件的bug,客户可以在上面自由添加他发现的所谓的bug,然后打个电话发给mail。。。告诉我:他添加了一个bug。我们把打电话发mail发信息这件事认为是这个bug的快捷方式。电话内容不涉及具体bug信息,电话只是一个提醒。我们直接在这个系统内讨论如何修复这个bug,或者在qq里面讨论,最终有一个人(我很乐意这么做)把内容收集了RE到这个bug下面。对于这个新的bug,我可以审核他,确认他是不是bug,或者只是用户的使用错误。对于一个进行中的bug,我可以修改他的状态,被cancel或者已经完成。

to be continued…

##评论


匿名2003-11-13 09:18:26 说: 关注~!