我们应该跟踪代码以外的其他事情吗？
在我职业生涯中的不同时间，我鼓励与我合作和/或管理的人员跟踪源代码以外的开发过程中的缺陷（即需求，测试，设计）。每次请求遇到惊愕，困惑和抵触。对我来说这似乎很明显，当人们抵制这个想法时，我总是有点震惊。我们应该跟踪代码以外的其他事情吗？
我们从这个练习中得到的是创建错误，其中的图片，并在那里被发现（在这个过程中的哪一部分）。如果我们正在制定不好的要求，那么我们就会知道它并可以改进它们。
是任何人都收集未在源代码中的缺陷信息？
是的，跟踪他们所有。
文档，设计文档，要求等
我也和你一样惊讶，当我听到“论据”反对。
至少跟踪系统应该能够识别发现缺陷的位置以及注入过程的哪个部分。
是的，绝对。围绕代码的工件 - 模型，规格，doco，需求信息，用例等 - 都可能包含影响代码本身的错误。
通常bug跟踪系统有一个假设，即他们的东西都是被固定或实施的列表。跟踪需求或其他文档（例如任务列表）中的错误似乎并不是一回事。更重要的是保持记录，以便您可以发现问题并评估是否可以减少问题。
我跟踪他们，但我们的bug跟踪系统之外。
好吧......任何你可以改善的地方，做一些可以改善的地方！
把它当作错误跟踪是很有道理的 - 正如你注意到的那样，观点会有所不同 - 但是使用一个跟踪系统会给出一个完整的全貌，让任务被分配等。也许一个演示，幻灯片放映或者旨在以超出原始源代码跟踪的方式使用这些系统的东西 - 图片说服的不仅仅是单词。
我通常追踪所有缺陷的来源。他们可能会在代码中得到修复，但他们不一定是由此造成的。
错误的要求，错误的解释要求，错误的设计，开发人员brainf * rt，错误的文档，错误的测试，缺少测试，过时的测试，不做开发者的代码，工具/编译器错误（非常罕见，在我看来），构建系统问题....
对我来说，他们都是“系统没有做客户需要什么就做”，所有预示着什么必须为了使被改变它做客户希望它做的事情。争论它是缺陷还是功能，或者源代码错误或其他问题会分散解决问题给我。
的一个大问题是进行同行评审何时开始难闻的气味和陷阱的数据库使用。
这是实际执行审查同行的宝贵资源。
它从长远来看肯定是有利的。这也应该是一个活的文件，数据库等被添加到为：
- 错误是固定的
- 作为同龄人进行审查，并
- 作为新鲜血液到达加盟的球队（S）带给他们新的知识和经验。
HTH。
欢呼声，
罗布
aboslutely。如果你的过程足够好，追溯缺陷的来源到很大。它可以帮助客户和设计人员确定其操作的限制条件。
顾客：开发机器人割草其中草的所有刀片都被切割到精确的均匀长度
设计师：我们将使用垂直安装于地面左手幼儿园剪刀确保清晰/精确的切割
质量保证：切割是精确的。
顾客：为什么需要机器人6天才能割草。我们需要30分钟或更少！
明确跟踪性能缺陷的来源可以帮助塑造对话并改进前进过程。
我们跟踪软件中的错误，文档中的错误，图纸中的错误以及所有使用相同轨道工具的新功能请求。
澄清：除了源代码之外，您是否跟踪其他缺陷？ – 2008-12-15 19:09:56
你可以跟踪你的同事的缺陷，但他们可能不喜欢它！ – 2008-12-15 19:23:10
喜欢华尔街吗？ – annakata 2008-12-15 19:58:39