摘要：我们刻板地制造些bug报告然后期望它们会象飞镖一样返回，这样我们可以检查看看bug是否被修复。 在这个星期的专栏里，Danny R. Faught分享了他从近来经历中提取出来的一些想法，那可能会使你在归档bug报告之后成为一个的客户代言人。

　　在bug返回之前

　　你所在团队中的人可能会给bug报告添加些意见，以作为正在进行中的关于怎样处理bug的对话中的一部分。 这给你了一个有关决定以及另外关于bug和修复性质的细节的好历史记录。在你提交bug报告并寄发出去之后，对你而言可能有更多的机会提供另外的有用信息。

　　在我当前的项目里，那些编程人员在他们学习新信息时，倾向于在分配给他们的bug报告里添加些意见。他们也可以添加意见在把bug转发给开发经理以寻求反馈。我有机会去查看是否有更多的我能够提供的有关问题性质方面但我不想在初提交bug时包括的信息。此外，我可能会评论并给出对已提议的修复将会如何工作的看法。比起在我有机会检查之前让编程人员彻底地实现一个修复，那大大缩短了沟通途径。

　　我们的bug追踪系统会在发布一条新意见时通知团队，那样很容易追踪这些谈话。如果你的系统使得看见意见被发布很困难，或如果活动将使得监视你所感兴趣的事情变得不实际，你可能不得不等待直到飞镖返回给你。此外，如果编程人员在他们正解决一个bug时对收到的反馈是持敌对态度时，你好遵从一个更加正式的流程。

　　When the bug is fixed， more or less.

　　飞镖回来了。。。在许多组织中，要求归档bug报告的人在修复完成后验证修复。或者你可能正为其他人提交的一个bug测试修复。我的目标是完成这一步骤时至少有和我开始时一样多的bug。

　　当然，你应该设法按你初报告它的方式增加bug。 有时，问题仍然存在，好象根本没有被修复一样。可能是因为配置管理的故障，并不在你所拥有的版本中修复。或许有些我既没报告，编程人员也认为不是重要的，关于我配置的特殊事项。当我拒绝一个bug被完全修复时，我试图包括关于我的配置和我如何重现bug的格外的一些细节。 与我第一次相比，我使用不同的词语以帮助减少任何的误解。并且我用一种表示为难而不是谴责的音调书写。 在大多数的情况下，编程人员真的努力去修复bug了，并且我们需要承认那份努力。

　　如果修复的很好但并没有将bug处理得令你满意，那该怎么办呢?你有打一个判断的电话。如果软件的变更代表了一些进度，并且如果没有更进步的改善，能够独立，然后我推荐关闭bug为已修复。 我不喜欢保持一份bug报告为open状态太久，从而产生太多的变化，而且可能多次改变它的焦点。

　　打开一份或更多的新的bug报告，描述你想看见的另外的变化。在关闭现有的缺陷之前做这件事将帮助确信你不会变得心烦意乱而忘记跟进，并且在你关闭旧的报告时，它将为你能在意见里为新缺陷引用ID号码。在相关的bug之间留下一个痕迹是很好的。

　　另一方面，如果修复真的未完成，继续拒绝它;把bug发回给编程人员。或许引入了一个明显的新bug，或者一些小的细节被忽略了。当代码在他们心里仍然很新时，编程人员彻底清理这些东西将会比等待一份新的bug报告而过滤系统更容易些。决定是拒绝修复还是提交一份新的bug报告通常是很艰难的，但是如果你已经与那些编程人员发展了一种好的工作关系，你按两种方式中的任一种都将得到一个好结果。

　　While you‘re at it...

　　当我检查一个缺陷修复时，我轻视在应用程序相同区域里的其他bug。如果代码正在增长或者变更地很频繁，我通常可以挖掘另外问题的问题来报告而不带很多的额外工作。Bug倾向于聚中在一起，并且bug修复倾向于暴露你以前不能看见的潜在缺陷。

　　即使你是在强硬的时间表压力下，花费几分钟归档一些bug是很值得的。支持探索测试的组织很有可能会了解到这次格外工作的价值。