process - 我们应该跟踪代码以外的东西的缺陷吗？

Question

在我职业生涯的不同时期，我鼓励与我一起工作的员工和/或设法跟踪除源代码之外的开发过程工件中的缺陷（即需求、测试、设计）。每次请求都遭到惊讶、困惑和抵制。这对我来说似乎很明显，当人们拒绝这个想法时，我总是有点震惊。

我们从这个练习中得到的是一张关于在哪里创建错误以及在哪里找到错误的图片（在流程的哪个部分）。如果我们正在构建不好的需求，那么我们就会知道并可以努力改进它们。

是否还有其他人收集有关源代码中缺陷的信息？

score 10 · Accepted Answer

是的，跟踪他们。

文档、设计文档、要求等。

当我听到反对它的“论据”时，我也和你一样感到惊讶。
至少跟踪系统应该能够识别缺陷的发现位置以及注入过程的哪个部分。

score 2 · Accepted Answer

2

绝对地。看看Ubuntu Bug #1。

于 2008-12-15T19:16:54.940 回答

score 1 · Accepted Answer

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

score 0 · Accepted Answer

通常，错误跟踪系统假设它们是要修复或实施的事物的列表。跟踪需求或其他文档（例如任务列表）中的错误似乎不是一回事。更多的是保留记录，以便您可以趋势问题并评估您是否减少了它们。

我正在跟踪它们，但在我们的错误跟踪系统之外。

score 0 · Accepted Answer

嗯……你可以改进的任何事情，都可以改进！

将这一切都视为错误跟踪是有道理的 - 正如您所注意到的，意见会有所不同 - 但使用一个跟踪系统可以给出一个连贯的大图，让任务被分配等等。也许是一个演示、幻灯片或针对目标的东西以超越原始源代码跟踪的方式使用这些系统——图片比文字更能说服人。

score 0 · Accepted Answer

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

错误的需求，错误解释的需求，糟糕的设计，开发人员的brainf * rt，错误的文档，错误的测试，缺失的测试，过时的测试，不符合开发人员所做的代码，工具/编译器错误（在我看来非常罕见） , 构建系统问题....

对我来说，它们都是“系统没有按照客户的意愿去做”，并且都表明必须改变一些东西才能让它按照客户的意愿去做。争论它是缺陷还是功能，还是源代码错误或其他问题会分散我解决问题的注意力。

score 0 · Accepted Answer

似乎没有人提到的一个大问题是创建一个包含不良气味和陷阱的数据库，以便在进行同行评审时使用。

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

从长远来看，它肯定会有所回报。这也应该是一个实时文档、数据库等，添加为：

HTH。

干杯，

抢

score 0 · Accepted Answer

绝对。如果您的过程足够好，可以追溯缺陷的来源，从而产生良好的效果。它可以帮助客户和设计师确定他们操作的约束条件。

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

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

QA：切割是精确的。

客户：为什么机器人需要 6 天才能割草。我们需要在 30 分钟或更短的时间内！

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

score 0 · Accepted Answer

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

9 回答 9