logo标签列表

你在一个缺陷跟踪器中寻找什么？

bug-tracking
4
我有兴趣评估缺陷跟踪器，但我想回到从什么样的标准是最重要的缺陷软件。到目前为止，我想到的包括：
- 与源代码控制的集成 - 易用性 - 基本功能（电子邮件通知，RSS，案例状态） - 自定义 - 高级功能（报告，可视化） - 稳定性 - 成本 - IDE 集成
有任何想法吗？
8个回答
11

易用性

在我看来，这应该是您评估功能时放在首位的一个特点。您希望内部开发人员和测试人员能够将他们在软件中注意到的任何问题都输入到工具中，即使他们正在处理其他事情。为了实现这一点，该工具必须非常易于使用，以至于它不会妨碍您的数据输入。最糟糕的错误是那些你不知道的错误。

一个屏幕上有15个以上字段，并且必须填写10个以上才能提交问题的工具并不是这样的系统。使用这样的系统，您会从测试人员收到关于小问题的便笺。

1
非常正确。但是你实际上忘记了最重要的人群：用户。开发人员和测试人员习惯于使用复杂的软件系统。而用户往往不是这样。因此，即使一个缺陷跟踪器在我们看来显得非常简单且功能不足，对我们的用户来说它可能仍然太过复杂了！ - Jörg W Mittag
我同意Jorg Mittag的观点，让用户体验尽可能轻松和简单非常重要。实际上，有很多次我没有提交错误报告，因为导航他们的错误跟踪器太令人困惑和耗时了。 - Aaron
那就是我的观点，虽然我在回答中提到了内部人员，但实际上我指的是每个人都必须能够轻松使用它。许多系统实现了一个简单的电子邮件收件箱，这应该足够容易让用户至少向系统报告问题，但如果他们以后需要查看案例，用户也应该能够轻松地添加或更改它。 - Lasse V. Karlsen
3

在评估BugTracker X时，BugTracker X的开发人员使用哪个缺陷跟踪器？

我不确定这是一个好的度量标准，因为有时人们会使用自己的产品，即使它们不好。 - Camilo Martin
1
  • 可定制的工作流程（从“打开”到“处理中”到“已解决”到“已关闭”）
  • 细粒度访问控制
1

关于这个问题，Hacker News 最近有一个讨论帖（链接）。里面有很多好东西！

1

一个API。必须的。

你必须能够从在现场运行的应用程序中捕获并自动提交错误到你的错误跟踪器。

1

（从"Lasse V.Karlsen"的答案复制/粘贴）

您想要内部开发人员和测试人员注意到软件中的任何问题并将其输入工具，即使他们目前正在处理其他事情。 为了实现这一点，该工具必须易于使用，以便它不会妨碍您的数据。 最糟糕的错误是您不知道的错误。

即使是好的、有责任心的测试人员，如果他们专注于测试组件A但偶然发现了组件B中的一个漏洞，如果在缺陷跟踪器中有很多阻力，他们可能不会真正输入该漏洞。 阻力意味着必填字段。 这并不是测试人员不称职或懒惰——这就是人类思维的方式。 我们关注焦点。 我们没有看到穿大猩猩套装的人。

Joel / FogBugz的理念是“无必填字段”，这是正确的方法（也是我自己BugTracker.NET的理念）。 您几乎总是可以稍后收集详细信息——操作系统、版本、浏览器等。

此外，如果您的应用程序具有 GUI，请看一下 "Bug Shooting"。您希望尽可能地让测试人员轻松地拍摄屏幕截图并将其放入 Bug 跟踪器中，这是一个非常好的工具。选择一个与 Bug Shooting 兼容或具有自己的专用屏幕截图工具的跟踪器。
我特别反感的是强制性的“组件”字段。你如何在软件内部组织是你自己的事情，而不是我的。我怎么知道应用程序是否因为RepositoryObserverFactoryFrobnicator或QuuxHandlerManagerTemplateStrategyThingamajiggy中的错误而冻结？ - Jörg W Mittag
在工作中，我们有一个“组件”下拉菜单，它是公司所有软件的全局设置.... - Corey Trager
0
分布式。我的版本控制系统是分布式的，为什么我的缺陷跟踪器不应该是呢？如果我在火车上修复了一个错误，为什么我可以进行修复但不能记录呢？
0
可能包括其他人提到的所有内容，以及我自己的一些想法。
如果您有长期的大型项目，并且有一个专门的测试团队来进行功能测试，那么您应该考虑以下几点：
- 缺陷是否可以与测试用例相关联（更精确地说是与给定的运行相关联）？ - 缺陷跟踪系统是否能够与测试管理系统交换数据？ - 它能否生成（有用的）报告？ - 缺陷是否可以按发布分组？

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接