是的，追踪他们全部。

文献、设计文档、需求等。

I am also as astonished as you when I hear "arguments" against it.
At the very least the tracking system should be able to identify where the defect was found and what part of the process it was injected.

当然。只需要看看Ubuntu漏洞#1。

是的，绝对的。围绕您的代码的文物 - 模型，规格，文档，需求信息，用例等 - 都可能存在会影响代码本身的错误。

通常缺陷跟踪系统的假设是它们是要修复或实现的事项列表。在需求或其他文档（例如任务列表）中跟踪错误似乎不是同一件事。更多是记录，以便您可以趋势问题并评估是否正在减少问题的数量。

我正在追踪他们，但是不在我们的错误跟踪系统中。

嗯，当然了……任何你能改进的，尽力去改进！

将所有东西都视为错误跟踪是有道理的-你所注意到的，意见会有所不同-但使用一个跟踪系统将提供一个连贯的整体图像，让任务被分配等等。也许可以展示演示，幻灯片或其他旨在使用这些系统的方式超出源代码跟踪-图片比文字更能说服人。

我通常追踪所有缺陷的来源。它们可能在代码中得到修复，但不一定是由那个造成的。

错误的需求，错误解释的需求，糟糕的设计，开发人员的失误，糟糕的文档，错误的测试，缺失的测试，过时的测试，代码无法完成开发人员的意图，工具/编译器错误（在我看来非常罕见），构建系统问题...

对我来说，它们都是“该系统不能按照客户的需求进行操作”，并且都表明必须进行某些改变，以使它能够按照客户的需求进行操作。无论是争论缺陷还是特性，还是源代码错误或其他问题，都会让我从解决问题的方向上分散注意力。

一个未被提及的重要建议是在进行同行评审时建立一个臭味检测数据库和陷阱。

这是实际执行审核的同行们的宝贵资源。

从长远来看，这肯定会收到回报。这也应该是一个实时文档、数据库等，随着不断添加：

• bugs are fixed
• as peers perform reviews, and
• as new blood arrives to join the team(s) bringing with them new knowledge and experience.

HTH。

干杯 (gān bēi)

罗布

完全没错。如果你的流程已经足够好，可以将缺陷追溯到起源，那就太好了。这有助于客户和设计师了解他们操作的限制。

客户：开发机器人割草，所有草的刀片都要割到精确的统一长度。

设计师：我们将使用装配垂直于地面的左利幼儿剪刀，以确保清晰/精确的剪裁。

QA: 割口非常精确。

顾客：为什么机器人需要6天才能割草。我们需要在30分钟内完成！

清楚地追踪性能缺陷的来源可以有助于塑造对话并改进未来的流程。

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