所谓“自定义”是指针对于当前很多软件项目中没有“产品说明书”或者没有合格的“产品说明书”这类现实主义情形而言的。

　　在上一篇文章中介绍了bug的“官方”定义和个人见解，其中涉及到了“产品说明书”这个对于当前一些软件项目而言尚属理想主义产物的东西，在这篇文章中，我分享给大家的是我之前所经历的一个类似的项目经历，当然也要献给大家一些我的“偏方”。

　　对于同一个问题，不同的人会有不同的看法，“一千个观众眼中有一千个哈姆莱特”是这个意思。这句话用来形容开发人员和测试人员对于bug的态度更加贴切了。很多的时候，当测试人员发现并提交了一个bug之后，得到的开发人员的回应是“This is not a bug”（这不是一个bug）或者“这不是一个严重的bug”之类，我第一次听到这句话的时候心情是相当沮丧，进而转化为愤怒。

　　没有“产品说明书”，凭什么这是bug？这的确是个问题。问题生来是被解决的，所以我们一定治得了它。直接天真的想法可能是建立起一套完善的机制，有了产品说明书不久结了么。果真是个好办法，可是太理想主义了，这如同老鼠挂铃铛故事中的那一群老鼠一样，办法是很好，但是却无法实施或者很难实施。一套合理的软件流程不是朝夕之间的事情，更何况一套完善的机制也不可能完全杜绝未定义bug。怎么办呢？另一种办法来了：有事好商量呗。

　　在进行讨论之前，测试人员还是有些准备工作要做的。对于“bug”这种罪大恶极的东东，我们应该列举其罪证。这个时候可能拿着《软件测试》上面的东西来解释显得有些苍白无力，这毕竟是测试人员的“圣经”却不是开发人员的。夸张点像两种信奉不同宗教的人一样，可以说是一个信奉上帝，一个信奉阿拉，你叫人家阿拉伯人跟着美国人信奉基督教，那显得有点过分了吧。更何况“圣经”上面讲的东西也是泛泛而谈，并没有严格指出bug到底长什么样子。这个时候更加合理的办法是列出自己的考虑的点，也有更有说服力的做法??找一些可以印证自己看法的知名软件产品中相同或者相似功能点，在这一方面“微软”可帮了不少“忙”。

　　开始讨论了，双方本着实事求是的态度来讨论这是不是一个bug，这如同一场法庭辩论。测试人员作为原告代理律师，开发人员作为被告代理律师，项目经理作为法官。记住，我们只是律师来的，所以宣判的结果并不会直接影响到我们，因此测试人员千万不要把自己当成原告，开发人员也不要把自己当成被告他爸（实际情况却经常这样，测试人员把bug当作自己的战利品，而那可是开发人员辛辛苦苦创造出来的软件啊），我们应该以理性的态度来审视这个待定的“bug”。开庭之后，原告代理律师陈述己方观点，接着被告代理律师陈述，然后双方进行短暂的和平而友好的辩论，然后宣判，不准上诉。

　　当然还需要注意的是，这个会议尽量不要占用大家太多的时间，也没有必要十分正式的邀请一大帮人来开会，但是开会完毕之后，测试开发双方要无条件接受讨论结果并及时进行相关的处理。

　　笔者经历的项目中，很多时候都是测试人员取得了终的胜利，这倒不是因为笔者强势或者咄咄逼人，更多的时候我拿出相关软件的例子之后并陈述为什么应该这样做之后，开发人员便接受了这样的解释。当然，有时候也是测试人员不了解软件产品相关领域知识而导致了误报bug，这个时侯测试人员应该心悦诚服地接受“This is not a bug”，这个时候任何多余的动作或者言语都是无效的，不仅不会给自己带来什么好处，也会给项目组带来不和谐的因素。在全民建设社会主义和谐社会的年代，大家都要和谐~

　　以上为个人意见，如有意见建议，欢迎一起交流。