精彩评论：
Sue C 在评论中写道：
所以问题是使用统计数据或者是缺陷数据库本身的问题吗？
我知道你想要衡量东西是，确定是否正在实现自己的目标。换句话说，更明智地衡量跟踪的问题。否则跟踪无关的信息是在浪费时间。
不管怎样，我会说bug跟踪数据库可以有价值。
我曾在一个较大的公司工作，那里有bug数据库，还曾经在没有bug数据库的一个小公司工作过。赞成和不赞成的观点如下：
赞成：
1、缺陷数据库为CYA服务。如果你的公司是做审查工作的，可以做为一个问题报告的记录。它仍然记录了项目结束或者QA验证问题修复的结果。
2、不容易错过缺陷，尽管可能有人会提出在做质量保证，我们应该整理这些bug报告不会错过问题。
3、一个bug数据库让查看打开状态的缺陷记录更容易些。例如管理者想把打开的缺陷进行分类。如果每个开发者都有他/她自己的bug列表，管理者很难去处理这些打开状态的缺陷的优先级。虽然你可以让每个开发人员给管理者发一份报告，但是如果在数据库中做这件事会更容易些。
不赞成：
1、我认为有些时候QA和DEV之间，仅仅是通过缺陷数据库沟通是效率不高的。通常，发一封邮件或者打印一份报告，然后跟相关的开发人员一起讨论问题更容易一些。从我的经验来说，严重依赖缺陷数据库可能会减少QA和开发人员之间的联系。在我看来，在QA和开发人员更直接的联系会有更有效的沟通，并且大家从这个过程中会学到更多。
可能的解决方案：除了数据库，测试人员和开发者之间有一个更直接的讨论问题的方法会减少对缺陷数据库的依赖。
2、我曾经工作过的很多公司都有缺陷数据库，但是查询功能很难用。查询大块的文本信息被禁用了。因此，我们不能知道是否有其他测试人员已经报告了同样的缺陷，如果能这样查询，会有更好处。
Joe Strazzere 说：
”有些人声称缺陷跟踪工具帮助他们分派任务和计划。一个带着便利贴的看板会更好的解决这个问题。“
或许你真的有足够大的白板和足够多的便利贴？又或者你有很少的bug要跟踪？
文章的标题是关于“bug 统计”，但是内容却是关于bug跟踪工具的。在我的店里两个东西是不一样的。在你那里是一样的吗？
你的观点“缺陷跟踪工具是安慰剂”仅仅是在敏捷团队中应用吗？或者甚至你认为在非敏捷开发环境中，相对于看板和卡片来跟踪缺陷，使用任何其他的东西都是在浪费时间？
