关闭

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

标签: 测试2010微软microsoftmanager
2897人阅读 评论(7) 收藏 举报
分类:

      马上就要过年了,现在周围都处在一种节日前的兴奋和喜气的的氛围,尤其是旁边的欧尚超市,超市入口处已被各种大红、大紫、大包的节日商品所占满,年味儿很足,很给力啊!最近正在读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了。

      真想知道这个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, 哈哈哈... ... !

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:634813次
    • 积分:7425
    • 等级:
    • 排名:第2944名
    • 原创:119篇
    • 转载:7篇
    • 译文:1篇
    • 评论:407条
    最新评论