Process 我们应该跟踪代码以外的其他方面的缺陷吗？

在我职业生涯的不同时期，我鼓励与我共事的员工和/或设法跟踪开发过程工件中的缺陷，而不是源代码（即需求、测试、设计）。每一次这个请求都遭到了震惊、困惑和抵制。在我看来，当人们抵制这个想法时，我总是有点震惊

我们从这个练习中得到的是一幅关于bug在哪里产生以及在哪里发现的图片（在流程的哪个部分）。如果我们正在构建不好的需求，那么我们将知道这一点，并可以努力改进它们

是否有其他人正在收集源代码以外的缺陷信息？

是的，跟踪所有缺陷

文件、设计文件、要求等

当我听到反对它的“论据”时，我也和你一样惊讶。

---

至少，跟踪系统应该能够识别缺陷是在哪里发现的，以及缺陷注入过程的哪一部分。

是的，肯定是。围绕代码的工件（模型、规范、文档、需求信息、用例等）都可能包含影响代码本身的错误。

通常错误跟踪系统会假设它们是要修复或实现的事情的列表。跟踪需求或其他文档（例如任务列表）中的bug似乎不是一回事。这更多的是一个记录的问题，这样你就可以找出问题的趋势，并评估你是否做得更少

---

我正在跟踪他们，但在我们的bug跟踪系统之外。

嗯，是的。。。任何你能改进的事情，做你能改进的事情

---

将其视为缺陷跟踪是有意义的-意见会有所不同，正如您所注意到的-但使用一个跟踪系统将提供一个完整的全局图，让任务分配，等等。可能是一个演示，幻灯片放映或其他旨在以超出原始源代码跟踪的方式使用这些系统的东西-图片说服多于文字。

我通常会跟踪所有缺陷的来源。它们可能会在代码中得到修复，但它们不一定会因此而产生

错误的需求、错误解释的需求、糟糕的设计、开发人员的头脑、糟糕的文档、错误的测试、缺失的测试、过时的测试、与开发人员不一样的代码、工具/编译器错误（在我看来非常罕见）、构建系统问题

---

对我来说，它们都是“系统没有做客户希望它做的事情”，并且都表明必须进行一些更改，才能让它做客户希望它做的事情。争论它是缺陷还是功能，或者源代码错误或其他问题会分散我解决这些问题的注意力。

当然。看看。

一个似乎没有人提到的大问题是建立一个臭味和陷阱数据库，供同行评议时使用

对于实际执行审查的同行来说，这是一个非常宝贵的资源

从长远来看，这肯定是值得的。这也应该是一个实时文档、数据库等，添加到：

• bug已经修复
• 同行进行评审时，以及
• 随着新的血液加入团队，带来新的知识和经验

嗯

干杯

---

罗布痛恨地说。若你们的过程足够好，可以追溯到缺陷的源头，那个么就很好了。它有助于客户和设计师确定其操作的约束条件

客户：开发割草机器人，将所有的草叶切割成精确的统一长度

设计师：我们将使用垂直于地面安装的左手幼儿园剪刀，确保剪切清晰/精确

答：切割是精确的

顾客：为什么机器人要花6天时间割草呢。我们需要在30分钟或更短的时间内完成

---

显然，跟踪性能缺陷的来源有助于塑造对话和改进后续流程。

我们跟踪软件中的错误、文档中的错误、图纸中的错误，以及对新功能的请求都使用相同的跟踪工具。

用于澄清：您跟踪源代码以外的缺陷吗？您可以跟踪同事的缺陷，但他们可能不喜欢！所以你提倡两个或更多的跟踪系统？这似乎违反直觉，浪费时间和资源。你仍然需要修复这个bug，即使它是文档中的bug。这是开源跟踪器的一个论点。只需搜索并用“有趣的情况”替换“bug”…我主张使用两种性质完全不同的跟踪系统。或者是我们配置的一个跟踪系统比我们现有的bug跟踪系统更好，它不太适合跟踪“项目经理忘记在讲义中更新X以满足Y”之类的事情。。。404。你是想讽刺吗？