一个好的BugTracking工具应该具备哪些能力?

3
我发现很多人询问最好的工具,但没有人问你真正需要哪些功能?还有哪些功能是你从未真正需要的?
(我发现自己在比较各种工具的功能矩阵。这是我讨厌的事情,因为最终我只会使用其中3-4个最重要的功能,而其余的则被忽略不用。)
6个回答

6

需求如下:

  1. 收集错误信息
  2. 按优先级/严重程度/到期日期等排序错误信息
  3. 将错误分配给开发人员
  4. 跟踪错误历史记录
  5. 将类似的错误链接在一起
  6. 将错误与客户关联
  7. 将已解决的错误链接到发布版
  8. 提供足够的信息或参考,以重现错误
  9. 可供多个开发人员使用
  10. 客户端能够访问错误状态

还有更多内容。


我发现如果错误/问题可以通过一个流程/过程进行处理,这对我很有帮助,在每个步骤中都会分配给特定的人员/区域。例如,首先由开发人员查找/修复,然后在修复后转到测试人员,最后转到支持人员以帮助解决更新/解决方案的问题。 - Feet

1

简单的最终用户数据输入。如果没有这个,你就不会有输入的错误,这等于毫无价值的错误工具。


1
我无法为你回答这个问题,因为我无法预测对你来说什么是重要的或者你的情况是怎样的:
- 你是一个大型还是小型的开发团队,还是一个独立开发者? - 是否有一个系统可以自动发送故障报告并在你的缺陷跟踪软件中创建事件,对你有帮助吗? - 能否预测发布时间表很重要,还是这只是你业余时间做的副业? - 与源代码控制的整合重要吗?
实际上,是唯一能够回答哪些功能对你而言是必需的。

1

以下是我认为最重要的三个必备功能:

  • Web界面,以便人们进行跟进
  • 源代码控制集成,否则很难追踪谁做了什么并部署补丁
  • 可配置的工作流程和电子邮件通知

1

我希望看到的功能:

1)投票 - 即这个漏洞影响了多少客户/用户?

2)严重性/优先级/其他 - 这些术语之间的区别微妙,通常(在我看来)不重要,但你必须知道这个漏洞有多重要。大多数工具都有这个功能,但过于复杂。

3)依赖关系 - 包括内部依赖(同一系统中的其他漏洞)和外部依赖(外部库、软件等)。实际上,大多数漏洞都有这个问题,但通常无法在数据库中表达,导致在分类时进行长时间而毫无意义的辩论。

我认为基本上没有意义的事情:

1)任何详尽的问卷 - 任何要求填写太多问题的漏洞跟踪器都只会得到糟糕的数据。这比没有数据还糟糕。

2)有争议的、但强制性的每日/每周/其他电子邮件通知。它们只会被归类为垃圾邮件/忽略/过滤掉。如果开发人员应该修复漏洞,但没有这样做,那就是管理问题。软件无法解决这个问题。


0
需要:
  • 电子邮件通知。
  • 状态
  • 组通知
  • 组权限
  • Web界面
  • 易于/快速的界面

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