如何在当前的bug跟踪过程中提出改进建议？

Question

我注意到我们当前的错误跟踪流程(TFS2012)中存在问题

a)引起错误的不一致b)记录错误的不一致c)错误解决的不一致d)由于较少的过滤器和有意义的值而难以应用过滤器。e)由于缺乏对TFS的培训，几乎不可能创建Bug报告。

我该如何向管理层提出变更建议，以供他们考虑。

Answer 1

欢迎来到SO @RON12345！

这是你在这里问的一个大问题，所以让我看看我是否可以把它分成可管理的块(明目张胆地从你的原始帖子中窃取，不会更少！)：

在引发bugs时不一致--你这么说到底是什么意思？在我看来，我猜你的意思是有些bug没有被写出来？如果是这样的话，可以通过使用一个简单的公理(我自己使用)来解决这个问题-“如果你必须问，‘这是一个bug吗？’，那么很可能是。对于大多数测试人员来说，这是一个思维范式的转变，意识到所有的bug都是错误的或可以改进的。

日志错误中的不一致-对于这样的事情，我使用了一种非常简单和公式化的方法：

<Brief bug description>

1. Repro
2. Steps
3. Go
4. Here

ACTUAL:  This is what is actually happening.

EXPECTED:  This is what the expected behavior is supposed to be.  (As an aside, try to avoid using words like 'should' here).

<This is where you make note of any attachments that go along with the bug.>

我们将bug分解到发现它的组件，找到它的sprint，并注意哪个团队需要进行修复。

错误解决中的不一致-我们在我当前的工作中使用以下内容作为解决状态：

Active -这个bug是新的，还没有被任何人审查过。

正在进行中-一个开发人员已经将这个bug移到了他们的队列中，现在正在对其进行审查。

已解决-此错误已修复，并已重新分配给报告它的人。

正如设计的那样-这可能看起来像是一个错误，但将通过代码更改来解决，或者由于其他因素(如其他团队对设计的更新)而实际上不需要修复。

无法重现-开发人员无法重现问题，错误可能需要更多信息或更好的重现步骤。

关闭-我认为这不需要解释:)

由于较少的过滤器和有意义的值而难以应用过滤器-这个问题可以通过在TFS中创建更有效的过滤器来轻松解决。例如，如果你是一个敏捷商店，考虑添加一个允许你通过sprint进行过滤的字段。

由于缺乏TFS的培训，几乎不可能创建错误报告-我在TFS中创建报告时发现了this article。

祝你和你的项目团队好运，我希望这个答案对你有用！