Bug统计是在浪费时间
openkk 12年前
<p> 英文原文：<a href="/misc/goto?guid=4958344121492173471" rel="bookmark">Bug statistics are a waste of time</a></p> <p> 五月初在跟敏捷团队谈论缺陷管理技术时，大家情绪有些激动。谈论的思想是团队中可能不需要跟踪缺陷的工具.看起来这个想法很另类。幸运的是，没 有人很直接的反对这个想法，参加讨论的很多人只是说如果不使用这个让人喜爱的东西，会造成一系列的混乱，并对此持有悲观的态度。</p> <p> 尽管 Lisa 提供了一些例子来说明这些工具什么时候会有用，我依然会采取更激进的做法：缺陷跟踪工具仅仅是一种安慰剂，就像希望做出一个更好的软件时，抛出一个硬币到喷泉并许下愿望，然后人们会得到一点点温暖和舒适的感觉。</p> <p> 几个人坚持认为缺陷跟踪挺重要的，但是他们不能用另外一种更简单及更高效的方法做这件事。一个大众性的观点是：使用缺陷跟踪工具是一个可重复使 用的雷达，让团队看到一个缺陷是否重现;不过这一点用自动化测试会更好些。另外一个观点是跟踪 bug，确保他们被修复。但是情况不是这样的。跟踪 bug 导致他们在数据库中积累起来直到被忘记。修复一个 bug 与修复系统菜单中难懂的标识相比，前者会得到更好的解决。有些人声称缺陷跟踪工具帮助他们分派任务和计划。一个带着便利贴的看板会更好的解决这个问题。更 大或者分散的团队也许会从计划管理系统中得到收益，除此之外有很多更高效和不怎么官僚式的计划管理工具要比缺陷记录器好不少。一个非常流行的观点是 bug 跟踪方便人们生成有用的报告，好像这是一个有说服力的论据。Bug 趋势也许对流程改变的跟踪效果很有用，但是你不是真的需要这种形式上的软件-你可以根据快速察看得到的数据生成趋势报告。</p> <p style="text-align:center;"><a title="bug or feature" rel="lightbox[18371]"><img title="bug or feature" alt="Bug统计是在浪费时间" src="https://simg.open-open.com/show/94cb06e07320dfc85ff27bec06268662.jpg" width="500" height="375" /></a></p> <p> 对软件质量来说，统计所有过去的 bug 是没什么用的，相对来说更实际的工作更有用些。但是做 bug 统计的人很多，并且很容易生成统计报告。 Douglas Hubbard 在《<a href="http://www.amazon.com/gp/product/B003GWX8YO/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=job0ae-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=B003GWX8YO" rel="nofollow" target="_blank">How to Measure Anything: Finding the Value of Intangibles in Business</a>》把这个现象解释成为衡量量倒置(<em>Measurement Inversion</em>) :</p> <blockquote> <p>衡量一个变量的经济价值通常与它通常所受到的关注度多少成反比。</p> </blockquote> <p> 一个常见的需要 bug 报告的借口是，管理者们需要知道软件的质量现状。由 Bug 来判断软件质量，这跟由湿度判断好天气一样不靠谱。有可能今天不会下雨，但这并不意味着我会喜欢它，除非外面是零下 10 度。Alan Weiss 在《<a href="http://www.amazon.com/gp/product/0071622101/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=job0ae-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0071622101" rel="nofollow" target="_blank">Million Dollar Consulting</a>》这本书里已经解释的很好了：</p> <blockquote> <p>质量，我耐心的解读这个词，并不是一些管理者眼中的那些，缺陷什么的。但是在消费者的眼中，质量就是有价值的东西。</p> </blockquote> <p> 衡量软件质量的报告很容易生成，但是价值很低，为什么不花一点更多的时间去确定实际的产品质量，然后再做出报告呢？一个有用的报告，再次强调一 下，是为了同管理者们一起帮助他们做规划，他们是要根据这些报告要做哪方面的决定，并且这些决定对他们来说有多大的价值。无论他们最终怎么样，这才是报告 信息的价值。由于来源的不确定性，这些决定和调查可以帮助我们衡量并减少不确定性。</p> <p> 不要执著于缺陷跟踪工具，好像他们是安全毯一样，在不同的背景下定义什么样的质量，例如大量的用户注册，会话的承载能力，准确的报告数据，衡量并且跟踪这些和相关风险。然后让它们<a href="/misc/goto?guid=4958344123875785010" rel="nofollow" target="_blank">形象化</a>！看看那些家伙在 <a href="/misc/goto?guid=4958344124677959495" rel="nofollow" target="_blank">Finn.no</a> 都做了什么-他们在那些跟他们主题有关的 推ter 作者们的个人简介，照片和人们的评论中解释这些问题。如果客户是快乐的，存在一些漏洞也是问题不大的。如果客户抱怨，跟多少 bug 是无关的。</p> <p> <strong>精彩评论：</strong></p> <p> Sue C 在评论中写道:</p> <p> 所以问题是使用统计数据或者是缺陷数据库本身的问题吗？</p> <p> 我知道你想要衡量东西是，确定是否正在实现自己的目标。换句话说，更明智地衡量跟踪的问题。否则跟踪无关的信息是在浪费时间。</p> <p> 不管怎样，我会说 bug 跟踪数据库可以有价值。</p> <p> 我曾在一个较大的公司工作，那里有 bug 数据库，还曾经在没有 bug 数据库的一个小公司工作过。赞成和不赞成的观点如下：</p> <p> 赞成:</p> <p> 1. 缺陷数据库为 CYA 服务。如果你的公司是做审查工作的，可以做为一个问题报告的记录。它仍然记录了项目结束或者 QA 验证问题修复的结果。</p> <p> 2. 不容易错过缺陷，尽管可能有人会提出在做质量保证，我们应该整理这些 bug 报告不会错过问题。</p> <p> 3. 一个 bug 数据库让查看打开状态的缺陷记录更容易些。例如管理者想把打开的缺陷进行分类。如果每个开发者都有他/她自己的 bug 列表，管理者很难去处理这些打开状态的缺陷的优先级。虽然你可以让每个开发人员给管理者发一份报告，但是如果在数据库中做这件事会更容易些。</p> <p> 不赞成:</p> <p> 1. 我认为有些时候 QA 和 DEV 之间，仅仅是通过缺陷数据库沟通是效率不高的。通常，发一封邮件或者打印一份报告，然后跟相关的开发人员一起讨论问题更容易一些。从我的经验来说，严重依 赖缺陷数据库可能会减少 QA 和开发人员之间的联系。在我看来，在 QA 和开发人员更直接的联系会有更有效的沟通，并且大家从这个过程中会学到更多。</p> <p> 可能的解决方案：除了数据库，测试人员和开发者之间有一个更直接的讨论问题的方法会减少对缺陷数据库的依赖。</p> <p> 2. 我曾经工作过的很多公司都有缺陷数据库，但是查询功能很难用。查询大块的文本信息被禁用了。因此，我们不能知道是否有其他测试人员已经报告了同样的缺陷，如果能这样查询，会有更好处。</p> <p> Joe Strazzere 说：</p> <p> ”有些人声称缺陷跟踪工具帮助他们分派任务和计划。一个带着便利贴的看板会更好的解决这个问题。“</p> <p> 或许你真的有足够大的白板和足够多的便利贴？又或者你有很少的 bug 要跟踪？</p> <p> 文章的标题是关于“bug 统计”，但是内容却是关于 bug 跟踪工具的。在我的店里两个东西是不一样的。在你那里是一样的吗？</p> <p> 你的观点“缺陷跟踪工具是安慰剂”仅仅是在敏捷团队中应用吗？或者甚至你认为在非敏捷开发环境中，相对于看板和卡片来跟踪缺陷，使用任何其他的东西都是在浪费时间？</p> <p> 原文：<a href="/misc/goto?guid=4958344121492173471" rel="nofollow" target="_blank">Gojko Adzic</a> 编译：<a href="/misc/goto?guid=4958185140659301754" target="_blank">伯乐</a>在线 – <a href="/misc/goto?guid=4958344126945406498" target="_blank">李岩</a></p>