在我职业生涯的不同时期，我鼓励与我合作和/或设法跟踪开发过程中的工件缺陷（除了源代码（即需求，测试，设计））。每次请求都遭遇惊讶，困惑和抵抗。对我来说似乎很明显，当人们拒绝这个想法时，我总是有点震惊。
我们从这个练习中得到的是一张图片，其中显示了创建错误的位置以及发现错误的位置（过程的哪个部分）。如果我们正在构建不良要求，那么我们就会知道它并且可以努力改进它们。
是否有其他人收集的信息不在源代码中？
答案 0 :(得分：10)
是的，跟踪它们。
文档，设计文档，要求等
当我听到反对它的“论据”时，我也像你一样惊讶 至少跟踪系统应该能够识别缺陷的位置以及注入过程的哪个部分。
答案 1 :(得分：2)
绝对。只需看看Ubuntu Bug #1。
答案 2 :(得分：1)
是的，当然。代码周围的工件 - 模型，规格，doco，需求信息，用例等 - 都可能包含影响代码本身的错误。
答案 3 :(得分：0)
通常情况下，错误跟踪系统会假设它们是要修复或实施的事物的列表。跟踪需求或其他文档中的错误（例如任务列表）似乎不是一回事。这更多的是保存记录，以便您可以趋势问题并评估您是否减少了记录。
我正在跟踪它们，但在我们的错误跟踪系统之外。
答案 4 :(得分：0)
嗯......你可以改进的任何事情，做一些可以改善的事情！
将错误跟踪视为有意义 - 正如您所注意到的那样，意见会有所不同 - 但使用一个跟踪系统会给出一个连贯的大图，让任务分配，等等。也许是演示，幻灯片放映或旨在以超越原始源代码跟踪的方式使用这些系统的东西 - 图片说服的不仅仅是文字。
答案 5 :(得分：0)
我通常会跟踪所有缺陷的来源。它们可能会在代码中得到修复，但它们不一定是由它引起的。
错误的要求，错误解释的要求，糟糕的设计，开发人员脑力，错误的文档，错误的测试，缺少测试，过时的测试，不做开发人员所做的代码，工具/编译器错误（非常罕见，在我的观点），构建系统问题......
对我来说，他们都是“系统没有做客户想要做的事情”，并且所有人都指出必须改变一些东西才能让它做到客户希望它做的事情。争论它的缺陷或功能，或源代码错误或其他问题是否会分散对我的解决问题。
答案 6 :(得分：0)
一个似乎没有人提到过的一个重要事件就是在进行同行评审时启动一个有难闻气味和陷阱的数据库。
对于实际执行审核的同行来说，这是非常宝贵的资源。
从长远来看，这绝对是值得的。这也应该是一个实时文档，数据库等，添加到：
HTH。
欢呼声，
罗布
答案 7 :(得分：0)
aboslutely。如果你的过程足够好，可以追溯缺陷来源。它可以帮助客户和设计师限定他们运营的约束条件。
客户：开发机器人剪草，将所有草叶切割成精确均匀的长度
设计师：我们将使用垂直于地面安装的左手幼儿园剪刀确保清晰/精确的切割质量保证：削减是准确的。
客户：为什么机器人需要6天才能割草。我们需要30分钟或更短的时间！
明确跟踪性能缺陷的来源有助于塑造对话并改进未来的流程。答案 8 :(得分：0)
我们使用相同的跟踪工具跟踪软件中的错误，文档中的错误，图纸中的错误以及对新功能的请求。