VS 2010 测试功能学习(21) – Bug 68648 : The Love Bug （转）

 马上就要过年了，现在周围都处在一种节日前的兴奋和喜气的的氛围，尤其是旁边的欧尚超市，超市入口处已被各种大红、大紫、大包的节日商品所占满，年味儿很足，很给力啊！最近正在读Alan Page、Ken Johnston、Bj Rollison合著的 -《How We Test Software At Microsoft》，经本人初步鉴定，这绝对是一本比较全面和系统介绍微软测试的好书，值得细细品味。并且还很新鲜，是2008年12月出版，书中的很多数据也是截止到2008年的。

      在本书的第9章Managing Bugs and Test Cases（第171页）中，介绍了一个非常有趣并且是真实的微软Bug - Bug#68648：The Love Bug。它是一位微软的男工程师利用Bug管理系统，向另一位微软的女工程师求婚的Bug，并且这位女工程师在Bug中表示接受他的求婚。我记得曾经在微软的一个培训活动中听说这个故事，当时只当是个笑话，这回在Alan Page（微软最早的一批测试构架师之一）的书中找到记载，看来是确有其事了。真是相当地有创意，值得各位未婚男性从业人员参考，呵呵呵！ 下面是从书中摘取的对这Bug的描述：

Bug 68648: The Love Bug

Anne,
Over a year ago, you identified a problem with Windows 95 and worked with my manager and the product group to get me up here to see if I could help get those problems addressed with Windows 98.
You provided me with suggestions and call data to get the appropriate visibility. Little did I know at that time that you would provide me with much more. You've given my life meaning, made me laugh, made me cry, and made me pick weeds. You know I have fallen madly in love with you. I love everything about you. I can't live my life without you. I know this is not the most romantic way to do this, but I would be forever happy if you would be my wife and share your life with me forever. Will you marry me?

Steps to reproduce:
1. Get married.
2. Reproduce.

Sorry, I couldn't resist.
Yes!
I can't believe you did this!

      Bug是测试活动的重要产物之一，它是团队不同角色协作的重要交汇点。作为测试人员而言，创建高质量和可重现的Bug报告是保证这一协作能够有效进行的前提。要能创建出高质量和可重现的Bug报告，需要测试人员有强烈的责任心、注重于细节、更要有耐心，此外还需要有一些专业工具的辅助。例如，之前曾经介绍的过的Visual Studio 2010 Test Manager， 参见之前的博客 《VS 2010 测试功能学习(十二) - 如何用MTM写出高质量的Bug报告? 》

      Bug Triage则是对Bug进行有效管理的核心，也是避免测试人员和开发人员之间关于“It's a bug.  No, it's not a bug but a feature. It's a bug indeed”这类不必要且伤感情的争吵的有效仲裁机制。所谓Triage是从医疗行业借用过来的词汇，是指根据现有医疗资源和病人的具体伤病紧急情况，对病人进行合理的分级，以保证优先出来那些最需要出来的病人。其实同样的道理也适用于Bug的出来，通过Bug Triage对每个进行合理的分级，决定哪些是需要优先处理的、哪些可以先缓缓、哪些是可以不需要修复、以及哪些更本就不是Bug而是By Design。这里有一个重点，那就是如何进行分级的标准（Triage Bar），这个标准在整个开发中期中不是一成不变的，实际上一个更具所处的不同阶段动态变化的标准。通常来说，在开发的一开始阶段这Bar是比较低的，也就是说，也就是大部分Bug都是要修复的；随着开发的深入，这标准是在不断提高的，到了临发布前，这个Bar达到最高点，这是只有是最严重的Bug，如：产品崩溃或者死循环等，才需要修复，而一些边边角角的Bug则是Won't Fix了。

      真想知道上面的The Love Bug当时是如何Triage的，哈哈哈！

      Bug Triage一般是由PM（项目经理或者程序经理），Test和Dev的三方代表定期进行的活动，其频率也不是固定的，更具需求可以动态调整。一般在产品开发的初期，频率可以不用很高，如果采用Scrum方式，则每个Sprint有1或2次就可以；当开发进入到最后阶段，Triage的频率就会很高，可以是每天一次以保证所有的新Bug都能得到快速的响应。这里有一个小短片，真是记录微软的Triage是如何进行的 - Inside a MS Build Bug Triage meeting。

      采用TFS的敏捷过程默认创建的工程中， 默认在每个迭代下都有一个“Bug Triage”查询项，它列出所有当前需要进行Triage的Bug。其实，它的查询标准很简单，就是找出所有当前是Active并且没有派发给任何团队成员去处理的Bug，如下图所示。你完全可以根据自己的需求创建自己的Bug Triage”查询。

 

      上面提到的The Love Bug，不简单是一次浪漫的求婚，它反应了微软的开发文化对Bug以及Bug管理的一种自然、和谐的态度。Bug不应该是冰冷的，更不应该是人见人厌的东东。之所以很多时候我们没能够用好Bug，造成了诸如：Bug“乒乓”、测试与开发因为Bug而水火不容的情况，往往是因为我们没能意识到Bug的功效和真正地管理好它。多些耐性，多些诚意，用平和心态善待好每一个Bug，也许你的Bug数据库也会出现象The Love Bug一样有创意的Bug， 哈哈哈... ... !