在上一篇文章中介绍了bug的“官方”定义和个人见解,其中涉及到了“产品说明书”这个对于当前一些软件项目而言尚属理想主义产物的东西,在这篇文章中,我分享给大家的就是我之前所经历的一个类似的项目经历,当然也要献给大家一些我的“偏方”。51Testing软件测试网 Dy r#YbZ4R+KV)` T
j.E4[,YM{0
对于同一个问题,不同的人会有不同的看法,“一千个观众眼中有一千个哈姆莱特”就是这个意思。这句话用来形容开发人员和测试人员对于bug的态度就更加贴切了。很多的时候,当测试人员发现并提交了一个bug之后,得到的开发人员的回应是“This is not a bug”(这不是一个bug)或者“这不是一个严重的bug”之类,我第一次听到这句话的时候心情是相当沮丧,进而转化为愤怒。
Ez&w| G@a;N5Hq^
q0
NB(X2W4_'T0
没有“产品说明书”,凭什么这是bug?这的确是个问题。问题生来就是被解决的,所以我们一定治得了它。最直接最天真的想法可能就是建立起一套完善的机制,有了产品说明书不久结了么。果真是个好办法,可是太理想主义了,这就如同老鼠挂铃铛故事中的那一群老鼠一样,办法是很好,但是却无法实施或者很难实施。一套合理的软件流程不是朝夕之间的事情,更何况一套完善的机制也不可能完全杜绝未定义bug。怎么办呢?另一种办法来了:有事好商量呗。51Testing软件测试网g_My&]
nBa V0Uoy
笔者经历的项目中,很多时候都是测试人员取得了最终的胜利,这倒不是因为笔者强势或者咄咄逼人,更多的时候我拿出相关著名软件的例子之后并陈述为什么应该这样做之后,开发人员便接受了这样的解释。当然,有时候也是测试人员不了解软件产品相关领域知识而导致了误报bug,这个时侯测试人员应该心悦诚服地接受“This is not a bug”,这个时候任何多余的动作或者言语都是无效的,不仅不会给自己带来什么好处,也会给项目组带来不和谐的因素。在全民建设社会主义和谐社会的年代,大家都要和谐~