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报告增加。