《转》零Bug策略:要么立马修复,要么忽略

上一篇 / 下一篇  2017-04-17 12:06:17 / 个人分类:测试管理

《转》零Bug策略:要么立马修复,要么忽略

http://www.51testing.com/html/63/n-3717163.html

发表于:2017-4-12 11:12  作者:Gal Zellermayer   来源:伯乐在线

字体:   | 上一篇 | 下一篇 | 打印 |我要投稿 | 推荐标签: Bug 软件测试管理 缺陷管理

  你在管理着多少个 bug,100,200,还是 2000 个?可能你自己也说不清,因为这个数字一直在变化。
  但我却能说出我们的 bug 数:0 个。
  你究竟在 bug 分派和管理上花费了多长时间,还是只能把它们从这个版本拖到下一个版本?
  作为一个团队经理(group manager),我每个月要花半小时的时间在 bug 管理上,并且同样的 bug 不会在我眼里出现第二次。
  你有没有考虑过,当你使用 Scrum 或其他敏捷方法工作时,要如何处理 bug 呢?
  答案就是使用 0 bug 策略。过去五年中,我参与过不同产品的 Scrum 项目,这个策略是基于我的工作经验得出的。
  我们也尝试过其他方法,但都宣告失败。例如,我们试过提升 bug 在产品待办事项中的优先级,但没什么用处。比起修复这些 bug,客户更倾向于给产品开发一些新功能,然后这些 bug 就会被推迟到下一次迭代中。
  0 bug 策略解决了这一问题。
  下面我们来了解一下 0 bug 策略,以及为什么我认为这是最好的解决方案。
  什么是 0 bug 策略?
  0 bug 策略是一种非常先进的处理 bug 的策略,但同时它也非常易于实施。
  你只需要谨记一条准则:不论何时对 bug 的处理方法只有两种选择,或修复它,或关闭然后不再去想它。
  如何实施?
  Bug 可以分为两类:
  · Bugs that were opened during the development of a new feature.
  · 开发新功能时出现的 bug。
  如果你们正在使用 Scrum 方法(或其他敏捷迭代方法),在实现用户故事(user story)的 sprint 过程中产生的bug。
  这类 bug 必须立刻修复,否则用户故事,或者说新功能的实现就会受到影响,而且你也违背了敏捷开发的原则:DONE is DONE(木已成舟,指开发完成就不再更改)。只有经过全方面测试,并得到客户的认可后,用户故事或新功能才能算得上是真正的完成。
  · 其他 bug(非 print 过程中产生的 bug)可以分为以下几种:
  · 回归 bug :由于开发新功能导致其他功能出现 bug 的情况。
  · 客户 bug :不是由项目组成员提出,而是由客户或用户反馈的 bug。
  · 在新功能/用户故事实现后才发现的 bug。这种情况不应该发生,但有时又无法避免,比如说当测试覆盖不足、进行 bug 跟踪或产品固化时都可能会发生。
  我们应该如何处理第二类 bug?
  · 立即修复(或在下一次 sprint 中修复,但不能拖到更晚了)
  · 如果修复这个 bug 价值不大,直接关闭不进行修复即可
  · 推迟解决(在几个月后或在下一个版本中再解决)
  永远不要推迟 bug,如果你现在无法修复它,那么你可能永远都不会再修复它了。
  那我们应该怎么做呢?或者选择修复它,或者关闭它,这就是 0 bug 策略的精髓。
  如下这种 bug 是必须进行修复的:两个用户无法同时进入 UI
  如果修复一个 bug 需要超过两天的时间,可以考虑不进行修复,举个例子:
  在 Safari 的使用过程中,当屏幕分辨率为768×1280 时登录页面中的帮助文本有些模糊。其他浏览器或其他的分辨率就没有这样的问题。
  可能有人会问,为什么不能推迟一些时间再解决这些 bug 呢?
  如果以后再修复,你需要花费比现在更多的时间和精力才可以。因为几周后:
  · 你可能记不太清,或你对 bug 的理解没现在这么清晰。
  · 验证错误和修复 bug 需要恰当的环境,几周后你需要投入很多时间来搭建环境。
  · 导致原始 bug 的代码可能发生变动,其他特性也可能会稍有区别。
  然而问题不仅仅是你需要投入更多时间才能修复 bug,这只是一个很小的方面。
  后续你还要对这些 bug 进行维护、分类和管理。无论是把它们放在产品待办事项中(在某些 bug 分类系统中),还是作为主要功能清单的一部分,你都需要对这些 bug 按优先级排序,这无疑会耗费很多时间。处理旧 bug 则需要更长的时间,因为你不能像熟知新 bug 一样那么了解它们了。同时,bug 分类也是很烦人的。
  根据我的经验来说,当经理、开发人员、产品所有者和架构师坐在一个 bug 法院(试图决定如何处理 bug)时,这场讨论将变成一场没有赢家的战争:
  · 开发经理:“现在修复这个 bug 有风险,不如推迟吧。”
  · 产品拥有者:“你根本没有考虑到用户体验,你没有为用户考虑!”
  · 开发人员:“我们可以不使用Java,只要做一个简单的 Go 模块就可以提升目标系统的性能。”
  · 架构师:“我建议放弃 extJS 转向 Angular,后者功能更强大,但需要一提的是,修复这个 bug 可能会带来安全方面的影响”
  · QA:“测试这个修复很简单,两个小时之内就能完成。当然,如果需要模拟多浏览器多用户的情况就需要几天的时间。并且我们需要确保在规模化的角度不会有回归测试。”
  你将永远无法修复这个 bug,它会永远存在你的系统里。这类 bug 会越来越多,它们会一直跟着你。你只能一次又一次地进行分类,把它们记录在每周的报告中,并且在质量指数中计算它们。
  为什么这些 bug 永远无法被修复?
  · 如果你现在不打算修复的话,意味着在现在和以后的版本中,你都有更重要的事做。
  · 随着时间的推移,你会推迟越来越多的 bug,这些旧 bug 还要和新功能和新 bug 进行竞争。所以,如果在没什么其他严重 bug 情况下这些 bug 还无法被修复的话,你凭什么认为以后就能修复它们呢?
  为什么不能在发布最后的加固阶段修复非 sprint 期的 bug?
  在加固阶段,你应该努力让你的版本更稳定一些。你要尽力寻找未知的问题,而不是在这时修复那些推迟的小 bug。
  不论何时,你都不可能修复所有的 bug,总会有一些被推迟到下一个版本解决。而在下一个版本中你肯定会发现新的 bug。那些低优先级的 bug 永远不会被修复,但你还需要花时间维护它们。
  也许 4 年后你决定不再修复它们,因为不值得的浪费精力。想象一下,如果在创建 bug 时就直接选择不进行修复,你将节省多少时间。
  为什么不能在空载时间修复它们?
  你不会有空载时间的,如果有的话,也会有更重要的问题等着你去处理。
  为什么不能在下一个版本中修复它们?
  你确定么?难道下一个版本没有新功能、客户、截止日期和里程碑么?
  当然开发人员都很喜欢那两周的错误修复时间,每次 sprint 有几个 bug 会使团队人员更高兴。
  如果一个新版本刚开始的时候,功能列表还是空白的,不如在创新或社交活动上投入点时间,你会受益良多。
  为什么不能在专门的 sprint 期中修复非 springt  bug?
  我们以前尝试过这种方法,的确有些好处。产品所有者没有选择,因为整个团队这段时间都在修复 bug,每个人都在做这件事,给人一种团队合作的感觉。
  然而我却不是很推崇它,因为这种方法只是处理了其中一小部分,根本没法消除日积月累的 bug,后期你仍然会面临这些问题,而且问题会更复杂。
  为什么不能把 bug 作为待办列表的一部分解决?
  实际上这也是个不错的选择,但需要注意:
  1、产品所有者很难理解为什么这些 bug 的优先级会比新用户故事要高,他们更倾向于用户故事。删除弹窗中多余的滚动条和添加搜索功能,哪个更重要呢?这将会降低产品的质量和研发热情。
  2、每个现在你无法修复的 bug后期会消耗更多的时间。推迟 bug 不符合成本效益。
  下面这张图展示了 bug 和用户故事混合记录的情况。我们尝试了将几个用户故事和 bug 放在一起处理:
  在此期间,项目组只需处理前三条内容
  产品所有者决定将第三项优先级降低,因为停止应用程序功能更加重要
  产品拥有者还不是很满意,因为搜索功能没在列表中提及
  我们和团队达成协议优先解决前三个用户故事,同时尽可能修复 bug。Bug 并没有得到修复。下次 sprint 的模式还是一样的,更多的bug 被积压,而新的功能都得到了处理。
  现在,我们同意 0 bug 策略是唯一的出路了。
  为什么0 bug 策略不常见?
  0 bug 策略不太常见可能有以下几个原因:
  我的产品已经有超过 1000 个 bug 了,我如何开始?
  花一个星期的时间浏览这些 bug,或者选择不再修复它们,或者在下一个 sprint 中进行修复。你需要做的就是把 bug 数变为 0,然后保持住。
  恐惧
  这可能是为什么人们不喜欢 0 bug 策略的真正原因。我曾向几个团队介绍了这种方法,但是由于恐惧他们都拒绝尝试:
  如果我们关闭了这个 bug,它就彻底消失了,我们永远也找不到它了!
  没错,就是这样,难道你没有感觉到解脱么?
  但是,如果我们关闭这个 bug,用户在使用产品时又发现它,不是还要重新修复么?
  既然这个 bug 如此重要,不如现在就动手解决吧!
  我们团队只有两个人,需要遵循 0 bug 策略么
  如果你们的团队只有两个人,就不需要任何策略,因为你们不应该有 bug,更不会去分拣它们。
  敏捷开发的主要原则是人大于过程, 0 bug 策略是否违背了这个原则?
  的确是,从我的经验来说,我更喜欢通过文化变革来解决问题,而不是增加过程。0 bug 策略是这个策略的例外。
  总结
  我可以诚实地说,使用 0 bug 策略并不是微不足道,相反它能带来很好的成本效益。对我来说,最难的部分可能是如何说服产品经理,这种方法是唯一正确的方式。这要求他们稍微放掉一些权利,这不是一件容易的事情。最好能让他们意识这个策略没有拖慢进度,反而大有用处。
  0 bug 策略还有另外一个作用,现在的开发人员追求更高的质量,没有人希望自己的代码出现错误。有了 0 bug 策略,他们知道如果现在不进行修复的话,bug 将被关闭。因此,开发者和产品才能向更高的质量标准迈进。
  这篇文章受到 Joel Spolsky 的博客 Software Inventory 的影响,但主要是我和同事在 VMware Israel 时完成的。

TAG: 修复

 

评分:0

我来说两句

Open Toolbar