Bug report之后

　　摘要：我们刻板地制造些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是很值得的。支持探索测试的组织很有可能会了解到这次格外工作的价值。

　　Not a bug?

　　哎唷。当某人说你如此仔细隔离并且报告的问题最终其实不是一个问题的时候，那是不好玩的。 这是我曾碰到过的一些新近的案例：

　　我正测试的软件有一个由第三方提供的关键组件。有几次我归档了一些开发人员在注释里说无能为力的bug。在那时，作为客户代言人我气坏了。用户不会关心问题是在我们的代码里还是其他人的代码里。他们只关心软件不能够工作。这样的话，我将尽力解释问题对用户的影响，并且可能建议我们一种绕过问题的办法。 我将会对一种变通办法可能是很昂贵来实现的事实感到敏感。

　　另一个例子是编程人员判定我认为是问题的bug根本不是一个问题。 我报告了一个可能会导致用户几个小时都不能登陆到应用系统中的bug。开发人员说这是期望的行为，并且得到开发经理的同意。我被在外投票决定，但并没有放弃。 与其在bug报告的意见里继续讨论，不如我给编程人员和经理发送一封解释我为什么认为不去修复问题是一个错误的电子邮件。不仅他们同意我，而且经理也通过把我的消息公布到bug意见中批准我的意见。 但是传奇到那里还没结束。我认为已实现的修复确实还不足以解决问题。 因为修复象设计一样工作并且没有引入任何新的问题，我把它关闭并且打开一份新的bug报告(要更多)。 鉴于已做的改进，我们全部能同意这个新请求是有效的，除了它的优先级别较低。

　　成为一个优秀客户代言人的关键是要考虑开发过程中的人性因素。在维持与编程人员和经理的有效沟通时，实践在影响用户的问题上坚守阵地的最佳艺术。但愿我在这些方面给你了一些有用的信息。

　　***************************************************************************************************************

　　A Bug Begets a Bug

　　摘要：Danny R. Faught在他的《After the Bug Report》(2005年4月专栏)一文中建议你在测试一个bug被修复时，也应该寻找另外的bug。这个星期，他详述了那个想法，让你看看一份bug报告怎样才可以增加更多的bug。

　　作为一个测试人员，你知道当你看见一个bug被修复时，你正在做你自己的工作。当你利用那个bug作为一个指南让你看看在你产品中的什么地方潜伏了更多的bug时，你可以做甚至更好的工作。我的个人目标是由于检查早先提交的bug的修复情况而打开至少一个以上的bug。

原文转自：http://www.ltesting.net