错误跟踪和帮助票据应该如何集成？

Question

我对错误跟踪系统（例如FogBugz）有一点经验，其中帮助故障单是问题（或可能是）错误，我有一些使用内部完全独立的错误跟踪系统的经验帮助中心系统。

我的问题是，在一家拥有现有（本土）帮助中心系统的公司中，如果不能选择更换它，那么如何将错误跟踪系统（可能是Mantis）整合到流程中？

现在帮助门票进入问题，问题等，并将它们分配给相应的人员（PC技术，帮助台工作人员，或者如果它是一个应用程序问题，他们无法在帮助台解决它被分配给开发者）。用户可以向帮助服务单中的应用程序发出小的修改或修复请求，并且分配给它的开发人员将在某个时间点进行更改，将他们的时间应用于该票证，然后在生成时关闭该票证

我们目前没有错误跟踪系统，因此我正在研究整合错误跟踪系统的最佳方法。如果是错误（或问题或功能请求），我们是否应该获取帮助票并将其放入错误跟踪系统中，然后如果不是紧急修复则关闭该票？我们可能不希望将bug跟踪系统公开给其他任何人，因为他们不知道在帮助中心系统中放什么以及在bug跟踪器中放什么......对吗？

有什么想法？建议？提示？建议吗？待办事项？不是为了？等...

Answer 1

在帮助台系统上有一个促销错误按钮，该错误按钮会在错误跟踪器上发布故障单，并附带适当的参考信息。

Answer 2

这是针对最终用户报告错误的生产系统，还是质量保证期间的问题解决？

如果是前者，有些现场人员应该对服务台门票进行分类，只记录一个真正的错误。

如果是后者，则根本不应该整合。

Answer 3

嗯，这是一个权衡。

我们使用单独的系统来获取服务台票证和错误。

优点：

• 工作流程＆amp;开发人员和服务台之间的要求可能不同，您可以为每个符合要求的系统选择一个系统（例如，仅与开发或帮助台相关的字段，不同类型的电子邮件集成）。
• 明确职责：服务台处理票证，开发人员处理错误。

缺点：

• 集成将不会非常无缝（您需要自动集成，这并不总是存在，或者人工可能忘记的手动后退链接）。

到目前为止，我们对两种产品非常满意。必须粘贴链接或关闭票证和错误有时很烦人，但通常票据和错误都由不同的人处理，所以这不是什么大问题。

如果您能找到适合每个人工作流程的产品，那么一种产品也可能运作良好。

Answer 4

在 raiseaticket帮助中心系统中，我们为Prod，Dev和Bugs创建了单独的工作流程。票证将根据问题的性质分配给相关组。这些票证不会暴露给任何其他组。因此，我们可以在我们的服务台门户系统中进行变通，以进行错误跟踪。