Bug report之后
--- Danny Faught《After the Bug Report》
--- Danny Faught《A Bug Begets a Bug》
---Kiki翻译于2005/10/12
***************************************************************************************************************
After the 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。
技巧：
为了在一个产品中找到更多bug，这是你可以使用一个已修复的bug作为启发的一些具体的方法：
- 查看第一个bug被发现的相同地方。你已经知道去检查bug的修复是可行的且没有引入新的问题。同样寻找可能被第一个bug掩盖了的潜在的bug。
- 在另一个平台上寻找相同的bug。你的产品可能被移植到不止一个的操作系统中，或者可能在一个本地化编译的应用程序和一个Web应用程序中有重叠的功能。看看你是否可以在实现的相同功能中找到一个相似的bug。
- 在产品的其他地方寻找一个相似的功能，以检查是否有相似的bug正在折磨着这些地方。你或许会发现由于修复bug引起的用户界面变更为了保持一致性而被传播到其他地方。
- 如果原先的bug涉及到一个极限场景，那么更远的推进到极限。 如果你使你的测试数据比以前更有压力或者不寻常，你可能找到另外的bug。
- 检查文档。Bug修复可能会改变用户可见的行为，因此用户文档可能需要更新以反映这些变更。如果你已明白了以前没有被文档说明的局限或一些难以形容的细节，那么考虑一下它在文档中是否可以帮助用户注意到这一点。
- 寻找和你正测试的bug修复无关的bug。如果你仔细地观察，沿着你从未尝试的方法你将留意到其他的bug。
当我仍然处于为发现另外的bug来归档的头脑风暴时，我发现保持已修复的bug为open状态和在我的队伍内是很有帮助的。 如果我被另一个任务，午餐等分心的话，我在bug库中仍然有这个提示，这在我试图立刻瞒骗很多任务的时候是特别重要的。 如果你的组织要求你尽快关闭bug报告，你可能需要改为保持一份关于测试想法的单独日志。
How It Fits In
当我利用一个已修复的bug来产生寻找另外bug想法的时候，我常常发现一阵新发现的我需要报告的问题。如果我没有找到任何格外的bug，并且实际上我允许open的bug数量下降，我会感到我好象遗漏了什么事情。如果你也有这样的感觉，那么你已成功的吸取了使bug增加的习惯。
我通常在我正在测试一个有着许多bug的产品时结束项目。如果你正在测试一个成熟的产品，你或许不能发现如此多的格外的bug。但是你直到自己看到了才会知道。
如果你被要求遵从一个非常结构化的流程，你可能会困难的发现足够多的时间去探究我所建议的你已计划责任之外的另外的地方。如果是那样的话，我推荐花一两分钟去看看是否你发现任何新的征兆。如果你这样做的化，告诉你的经理你对你所发现问题的担心，并且询问可否安排一些时间去探究那些地方。你或许已发现所测试应用程序的一个区域。如果你已徘徊在其他人负责测试的地方，和他分享你的发现，并且利用他在最佳方法上的专业知识以指出那个区域中的问题。
你或许正在疑惑我为什么不建议你在归档一份bug报告之后使用这份checklist，而不是等到缺陷被修复后。这些信息可能帮助你更进一步隔离你已发现的一个bug或者基于你刚报告的一个bug发现更多缺陷。不过，我建议在一个bug被修复之后使用检查表是因为在那点上经做了一个设计的决定已。 一旦你知道一个bug如何被修复， 你有关于在你最初报告bug的时候很难预言的修复的范围的有价值信息。一旦你知道已经被应用修复的地方的边界，你准备用另外的测试想法去探索那些边界。
这些想法已经帮助我提交过一次bug报告的无情的猛攻。当open的bug数量继续提高时，开发人员最好的希望是bug的严重级别正在平均的减少。 我希望你能使用一些这些想法使你自己的bug报告增加。
2577
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
