衡量一个变量的经济价值通常与它通常所受到的关注度多少成反比。

　　一个常见的需要bug报告的借口是，管理者们需要知道软件的质量现状。由Bug来判断软件质量，这跟由湿度判断好天气一样不靠谱。有可能不会下雨，但这并不意味着我会喜欢它，除非外面是零下10度。Alan Weiss在《Million Dollar Consulting》这本书里已经解释的很好了：

　　质量，我耐心的解读这个词，并不是一些管理者眼中的那些，缺陷什么的。但是在消费者的眼中，质量是有价值的东西。

　　衡量软件质量的报告很容易生成，但是价值很低，为什么不花一点更多的时间去确定实际的产品质量，然后再做出报告呢？一个有用的报告，再次强调一下，是为了同管理者们一起帮助他们做规划，他们是要根据这些报告要做哪方面的决定，并且这些决定对他们来说有多大的价值。无论他们终怎么样，这才是报告信息的价值。由于来源的不确定性，这些决定和调查可以帮助我们衡量并减少不确定性。

　　不要执著于缺陷跟踪工具，好像他们是安全毯一样，在不同的背景下定义什么样的质量，例如大量的用户注册，会话的承载能力，准确的报告数据，衡量并且跟踪这些和相关风险。然后让它们形象化！看看那些家伙在Finn.no都做了什么-他们在那些跟他们主题有关的twitter作者们的个人简介，照片和人们的评论中解释这些问题。如果客户是快乐的，存在一些漏洞也是问题不大的。如果客户抱怨，跟多少bug是无关的。

　　精彩评论：

　　Sue C 在评论中写道：

　　所以问题是使用统计数据或者是缺陷数据库本身的问题吗？

　　我知道你想要衡量东西是，确定是否正在实现自己的目标。换句话说，更明智地衡量跟踪的问题。否则跟踪无关的信息是在浪费时间。

　　不管怎样，我会说bug跟踪数据库可以有价值。

　　我曾在一个较大的公司工作，那里有bug数据库，还曾经在没有bug数据库的一个小公司工作过。赞成和不赞成的观点如下：

　　赞成：

　　1、缺陷数据库为CYA服务。如果你的公司是做审查工作的，可以做为一个问题报告的记录。它仍然记录了项目结束或者QA验证问题修复的结果。

　　2、不容易错过缺陷，尽管可能有人会提出在做质量保证，我们应该整理这些bug报告不会错过问题。

　　3、一个bug数据库让查看打开状态的缺陷记录更容易些。例如管理者想把打开的缺陷进行分类。如果每个开发者都有他/她自己的bug列表，管理者很难去处理这些打开状态的缺陷的优先级。虽然你可以让每个开发人员给管理者发一份报告，但是如果在数据库中做这件事会更容易些。

　　不赞成：

　　1、我认为有些时候QA和DEV之间，仅仅是通过缺陷数据库沟通是效率不高的。通常，发一封邮件或者打印一份报告，然后跟相关的开发人员一起讨论问题更容易一些。从我的经验来说，严重依赖缺陷数据库可能会减少QA和开发人员之间的联系。在我看来，在QA和开发人员更直接的联系会有更有效的沟通，并且大家从这个过程中会学到更多。

　　可能的解决方案：除了数据库，测试人员和开发者之间有一个更直接的讨论问题的方法会减少对缺陷数据库的依赖。

　　2、我曾经工作过的很多公司都有缺陷数据库，但是查询功能很难用。查询大块的文本信息被禁用了。因此，我们不能知道是否有其他测试人员已经报告了同样的缺陷，如果能这样查询，会有更好处。

　　Joe Strazzere 说：

　　”有些人声称缺陷跟踪工具帮助他们分派任务和计划。一个带着便利贴的看板会更好的解决这个问题。“

　　或许你真的有足够大的白板和足够多的便利贴？又或者你有很少的bug要跟踪？

　　文章的标题是关于“bug 统计”，但是内容却是关于bug跟踪工具的。在我的店里两个东西是不一样的。在你那里是一样的吗？

　　你的观点“缺陷跟踪工具是安慰剂”仅仅是在敏捷团队中应用吗？或者甚至你认为在非敏捷开发环境中，相对于看板和卡片来跟踪缺陷，使用任何其他的东西都是在浪费时间？