您如何记录独立于产品/技术的修复错误的过程？

Question

找到bug跟踪工具似乎相对容易，但我正在寻找一种方法来记录修复缺陷的过程，这些缺陷将跟踪如下内容:谁在处理它，确保它不会干扰其他缺陷或应用程序的其他稳定元素。

我们希望促进适当的沟通，以确保工作不会重复，而且我们对所有的移动部件都有很好的感觉。我们是顾问，致力于一个复杂的应用程序，这是受许多监管要求。

Answer 1

这是您的跟踪工具应该处理的东西，并且应该内置到工具中的流程流中。(也就是说，它并不总是这样工作的)

如果你是从零开始，你几乎肯定会发现，你开始的将需要改变。当您在工作流程的不同阶段遇到棘手的区域和痛点时，您的流程将不断发展。

你想要在你的跟踪工具中拥有的东西：

• 将相关问题联系起来的能力。
• 标记重复问题的能力(这可以作为链接的子集来完成)。
• 定义工作流的能力(也就是说，允许的状态问题可以在其中，数据必须与其关联才能移动到下一个允许的状态之一)
• 能够很容易地报告谁被分配到什么以及他们所处的阶段的能力。
• 链接/附加相关文件的能力(如链接到法规要求等)。

您可能需要将其定义为工具之外的流程的内容：

• 回归检查(唉，这是确保修复不干扰应用程序其余部分的唯一方法)和任何回归问题的升级
• 问题分配的流程(何时将问题分配给测试人员，如果存在问题，是否来回传递，等等)
• 监管需求与流程之间的交互(这几乎可以肯定是您必须定义的)。
• 你的团队如何使用这个工具

我希望无论你做什么，一开始你会有很多困惑，甚至可能更糟。会发生的情况是，当您习惯于使用该工具时，您会发现您的初始流程不像您想象的那么好。这是当您修改您的流程，以顺利通过这些领域的工作流。

这将是尴尬的，一开始似乎有点过分(从这里的经验来看:我让我的雇主的开发团队从excel电子表格到使用Microsoft team Foundation Server进行问题跟踪和工作流--我们已经使用TFS将近一年了，我们仍然在改进流程，并根据我们的需要定制TFS )，但它确实变得更好了。

根据我的经验，我有几点建议：

• 当在跟踪系统中发送有关项目的电子邮件时，使用项目ID和标题作为电子邮件标题。如果你不能自动链接电子邮件到项目，这至少使它更容易跟踪讨论和问题。
• 有人需要“拥有”跟踪系统，并处理对它的任何定制/更改。
• 有人需要“拥有”每一个问题，以确保问题得到正确的处理。无论是团队领导、项目经理还是其他人，都将取决于您的系统。
• 对于流程的第一个版本，您可能希望从当前流程以及监管要求开始。这将给你一个合理的起点，当你发现一些不太好的东西时，你可以改进它。
• 在可能的情况下，尽量保持这些变化小而不明显.太多的更改可能会使您的团队不堪重负，并造成混乱--当他们熟悉应用程序时，他们将已经在处理许多新的事情，所以他们需要处理的其他更改越少，就越不可能有东西掉落。

祝好运

Answer 2

@Kate提到了许多特征。怎么去那里？有免费的工具可以吗？

我们使用：

• 高度定制的Bugzilla (添加自定义字段以支持我们的自定义工作流过程)
• 不同类型的bug有不同的工作流，
• wiki用于文档处理，维护核对表等Foswiki引擎
• 我们运行自定义SQL查询，以跟踪bugzilla中的所有bug是否都遵循该过程，并显示该过程的异常(因此bug不会被遗忘和崩溃)。使用带有指向其他wiki页面和bugzilla超链接的Foswiki插件，很容易在wiki中发布SQL结果。
• 我们单独跟踪反馈(大多数反馈不会导致错误，但有些可能会转换为多个)
• 当然，不可避免的白板上还会有便条来区分bug的轻重缓急和方便错误分类。

我们花了很多年才把我们的过程微调到这个阶段，我们正在根据需要做更多的调整。

所有工具都可以按特定步骤发送电子邮件，但我们依赖于中央数据库(带有web前端)来处理状态。电子邮件对此没有好处。

我们的工具(bugzilla，Fos wiki，反馈)是基于Perl的。越来越难找到Perl专家。有非常好的基于Python的解决方案TRAC，它集成了bug跟踪器、用于文档的wiki以及与代码查看器(在所有部分中都有标记链接到bug编号、变更集、wiki页面等)的subversion。非常整洁，但转换我们的数据将是一场斗争，所以我们还没有切换。

Wiki是整个图片中非常重要的一部分，因为它允许您生成超链接的网页，并且没有预先定义的结构(所有的智能都在插件中)。除非你使用令人厌恶的东西，比如分享点，这是很容易开始，但几乎不可能定制。