先来讨论一下“小鸡报告问题”的寓言故事，测试人员由此可以得到如何妥善处理软件疑难缺陷的一些有益启示。

　　小鸡住在森林里，一天突然有一个橡胶果掉在它头上。这可把它吓坏了，浑身瑟瑟发抖，连身上的毛都掉了一半。“救命啊！救命啊！天塌了！我一定要告诉国王！”小鸡说。

　　于是，小鸡满怀恐惧地去告诉国王。路上碰到了大公鸡。

　　“你要去哪儿，可爱的小鸡？”大公鸡问。

　　“啊，救命！天塌了！”小鸡怯怯地说。

　　“你怎么知道的？”大公鸡惊奇地问。

　　“我亲眼所见，亲耳所闻，有一块天掉到我头上了！”小鸡说。

　　“可怕，真是太可怕了！我们得赶紧报告国王。”大公鸡说。言罢，它们用最快的速度向国王的宫殿奔跑。

　　在这个寓言故事里，小鸡在意外事件发生时大吃一惊，然后就疯一般地逃跑，向全世界大声宣布臆想的事情发生了。而大公鸡听了小鸡的一面之词后，没有深入思考和检查确认，就听信了小鸡。想象一下，软件测试人员是否有时候因为发现了一个自认为非常严重的缺陷而会像小鸡一样大惊小怪。猜想一下，项目经理和软件开发人员假如看到了小鸡和大公鸡这样逃跑会怎样做？

　　这个看似荒诞的寓言故事与软件测试存在很多有趣的类似之处。软件测试人员与软件开发人员对软件缺陷的确认、修正和验证等处理，可能经常出现不一致的认识，甚至可能引起激烈的辩论，这时候就更体现了处理某些具有争议缺陷的策略的重要性了。

　　1、缺陷还是功能特征

　　软件测试过程中经常有这样的情况发生：软件测试人员报告的缺陷，软件开发人员不认为是缺陷而是软件的特征，从而拒绝修正。遇到这种情况，站在软件测试人员的角度，应该如何妥善的解决问题呢？

　　很显然，与那些固执的开发人员辩论、争吵是无济于事的，那样只会把关系弄糟。确定某个软件行为特征是否是缺陷，需要首先从分析软件的系统需求、设计文档以及用户的实际需要寻找答案。

　　最理想的情况是软件的设计文档中明确规定了软件特征和功能，但是实际情况是，软件的需求和设计文档写得很粗，甚至没有文档，或者文档零散地以电子邮件、产品计划和市场材料的形式存在。在这种情况下，测试人员和开发人员之间对软件的某个表现特征是否属于软件缺陷，就可能产生分歧。

　　如果对于是否是缺陷的争议是由于团队内部交流不畅引起的，那么测试人员、开发人员和项目经理一起讨论和交流，测试人员首先要确认软件缺陷的具体现象是什么，为什么认为是软件缺陷。如果是由于测试人员对软件设计文档的错误理解引起的误报，则可以关闭错误。

　　如果每个人都理解软件测试人员描述的软件缺陷，但是开发人员仍然不承认是软件缺陷，应该如何处理呢？软件开发人员可能由于任务压力大，没有时间修正缺陷，或者认为这个缺陷不值得修正，或者坚持认为软件就是故意这样设计的，属于软件的特征之一。

　　但是作为测试人员是站在最终用户的角度看待软件缺陷，如果认为缺陷对最终用户的使用具有很大的不利影响，则测试人员需要坚持原则，召集更多的人员参与讨论，例如，市场人员、技术支持人员、质量保证人员等。

　　很多公司在项目实施之初就成立了由测试经理、项目经理和质量保证人员等组成的测试仲裁委员会，他们对是否属于软件缺陷具有最终的裁定权利。