"Not a bug" VS "Won't Fix"

  
经常听到开发和QA如下的对话：
 
Case 1:
  QA：“在我机器上工作不正常”；
  Dev: 换个干净的机器试试；
  QA: 干净的机器是好的。
  Dev: 那是你机器的问题，不是Bug.
  QA: ....

Case 2:
  Dev: 你为什么要报这个bug呢，我的代码都是对的啊，我的程序都是没问题的啊！;
  QA: 可是程序不应该有这个结果啊";
  Dev: 我的程序是没有问题的，为什么结果不对我就不知道了，你把这个bug关了吧！
  QA: .....  

Case 3:
  QA: 程序Crash了；
  Dev: 步骤是怎样的？
  QA: 放在那里就Crash了；
  Dev: ....
  Dev: 可以重现吗？
  QA努力中。。。
  QA: :( 无法重现
  Dev: 那好吧，这不是个bug.
  QA: .....

Case 4:
  QA: 这个功能好像不好用哎！
  Dev: PM就是这样设计的。
  QA:  那这是个bug吗？
  Dev: PM是这样设计的，所以不是个bug。

Case 5:
  QA: 这台机器上会Crash;
  Dev: 其它机器呢？
  QA: 其它机器不会。
  Dev捣鼓半天，没发现原因。
  Dev： 机器问题，不是Bug;
  QA: .....

       上述Case虽然也许略有夸张，但绝对是真实世界中会出现的问题，有些也就是我听到过的一些对话。此外，还有，系统问题，硬件问题等等， CSDN上不是发过一篇搞笑文章描述开发遇到bug时候的反应与借口么，总之，这不是个bug，关掉吧！或者，至少，这不是我引起的bug，关掉吧！于是大家都开心了，隐患埋下了！

       平心而论，一个软件产品没有bug是不可能的。而且，不是所有的bug都可以改掉，更不是所有的bug都需要修正，但是，直接下结论说，It is not a bug, 显然不合适。

        在干净的机器上无法重现的bug就不是bug吗？只在一台机器上重现的bug难道就不是bug吗？显然是个bug。没有人知道最终用户的机器环境是什么，也许正是由于我们的程序逻辑考虑得过于简单以至于忽略了真正的用户Case呢，这其实是个改进产品的大好机会啊！

        无法重现的bug就不是bug吗？显然也不是；如果程序或者系统没有问题，就理当每次都工作正确。我认为，正确的方法，首先还是努力尝试去解决问题；首要的自然是重现，无法重现的话，偶尔一次的重现也能够留下蛛丝马迹，可以获取到Dump或者日志等等信息，结合代码去调试，也许能发现重大的问题呢！即使实在无法重现，无法修改，可以设置为"Won't fix"，并加以描述，而不是简单的关闭了事！

        所以，不要轻易的下结论说"It is not a bug." 我认为，除非QA完全误解了需求或者弄错了测试方法，否则，QA觉得不对的地方都应该当做一个Bug来对待。

        也许，程序的表现行为与产品定义一致，但测试人员仍然觉得难用，那么这是一个产品定义上的bug，应该由Product Manager去负责跟进；
        也许，代码是正确的，但产品行为不正确确实是由于系统或者硬件原因引起的，那么这仍然是一个bug；一种方法是想办法绕过系统或硬件的缺陷；另一种办法是作为Known issue列出，然后设置为Won't fix。而最理想的还是从别的角度帮助最终用户避免出现类似的问题，用户可不知道你的代码是正确的；
        也许，这个问题并不重要，那么设置为Won't fix,说明你的原因，没人会苛责你，我们需要取舍，将时间放在最重要的问题上，但这仍然是可以改进的地方；
        也许，这个问题太难修改，那么也可以在估算成本和收益之后设置为Won't fix；
        同样的，如果是个无法重现的bug或者重现概率很低的bug，毫无疑问设置为Won't fix也是恰当的。
        同时，记住，当这些设置为Won't fix的问题在最终用户环境中大规模出现的时候，或者当你需要做代码重构的时候，都需要对这些问题留意，因为，很有可能，你的代码中存在着重大的漏洞才引发这些难以察觉难以重现的问题。

         更为重要的是，一旦开发人员不愿意承认这些是存在的问题，既会打消测试人员的积极性，更可能从开发人员的视角去主导测试控制测试，这样，测试人员更难从最终用户的角度来发现问题和保证产品质量。

        所以我觉得，VSTS 2010中将"Won't Fix"作为Item的状态之一并与Trash区分开来实在是有非常充足的理由啊！

        上面是我个人的一点体会，也许更适合Windows平台下的应用类软件吧，因为这些产品的测试人员会更接近于最终 用户一些！但即使在其它领域，承认Bug是难以重现的，难以修改的或者说不重要的，也比完全忽视这个bug要好得多！