关于漏洞追踪的五项原则

远程工作的团队相比同坐在一个办公室工作的团队需要更好地纪律性，沟通的纪律性。过去的五年，我们远程地在 teamed.io 开发软件。我们使用漏洞追踪工具（如 Github, JIRA, Trac, Basecamp 等 ）。我们不鼓励里斯爱里面通过如Skype，HipChat，电子邮件或者电话来沟通问题。对我们来说每一个漏洞都有一个生命周期，自己的参与者，和自己的目标。这么多年来，我们积累了很多经验想和大家分享。如果你也是远程协作开发，你会发现很有用。

1.保证漏洞是一对一的

每个漏洞都是两个人之间的一种联系：问题提出者和问题解决者。如果是个漏洞，那么我提出这个问题，你来解决这个问题。如果是个问题，那么我来问你来回答。如果是项任务，我让你来做，你来完成它。基本上所有情况都是两个主要角色。不管多少人涉及到了问题的解决，总是有两个通常意义上的角色在。

漏洞提出者应该从问题出发来着想。我报告了问题，那么我坚持这个问题的存在，因为这是我的职责。其他人可以告诉我这不是问题，我是不是搞错了，他们可能告诉我这个漏洞不能复现，他们可能告诉我我提的问题太模糊了，没人看得懂。他们也许会告诉我我提的漏洞有很多问题。但是我的职责就是来提出问题，保证漏洞的存在。很明显，如果问题不能复现，我会强制关闭。但是直到问题关闭，我都是这个问题的守护使者。：）

另外，漏洞解决者的职责是保护漏洞解决方案。如果一个问题提到我这里，我必须得解决掉。我的工作就是告诉漏洞提出这我的解决方法足够好。他也许会告诉我解决方案不够充分，不是最优解，或者不是完成的。我的工作就是坚持我是对的。我需要首先了解问题，找到到这问题的各种原因然后寻找最优的实现方案。但这些都是次要的，我的主要任务是说服测试人员。我会一直铭记关闭问题单是我的首要问题。

我的意思是不管多少人参与到问题当中，永远记得有个人在向另一个人说明问题原因，提出解决方案。问题涉及的其他人都是种辅助或者说累赘。（继续往下看）

2.关闭问题单！

记住漏洞不是一场聊天。通过聊天可不能关闭问题。问题到你名下，尽快专注的解决问题才是最重要的。

另外请记住越快解决问题，你对项目做得贡献越大。长时间未解决的问题单就是梦魇。记录管理它们都是很困的。很难理解发生了什么。你见过开源项目中存在两年的问题虽然有几百评论但是没有解决的么？这是项目管理者的过失，也是问题参与者的问题。每个漏洞都应该短时间内被关注。1.问题描述 2.问题细化3.简要解释 4.解决方案 5.关闭，并感谢大家。这才是理想的情景。

当你意识到你的问题要拖很久，你就要更努力的让问题尽快解决。如果测试人员不喜欢我的解决方案怎么办？那也需要找个暂时的解决方案来让测试人员满意。在你的代码或者项目中使用TODO标签也比拖着问题不解决管用。

一旦你提供了足以解决问题的方案时主动去找测试人员关闭问题。直接关闭问题，不要兜圈子。直接要求测试人员关闭问题并继续后续工作。可以这样说：“hi，杰夫。如果没有其它问题，请关闭这个问题单。”

3.不要关闭问题！

每当你发现漏洞报告漏洞的时候你都在耗费这项目的资源。每个漏洞报告都意味着资金的花费。1，你发现提出问题的时间不是免费的。2，项目经理需要花费之间来查看问题单并分配问题单。3，开发人员也需要花费时间经理来阅读你的测试报告并找到解决方案4 每次问题讨论都要有很多人的参与。

可以使一个临时的解决方案，可以使项目文档中一行文字的变化，甚至可以是个TODO标签写着：我们知道问题，但是我们有点懒不想改。总之做一些事情总比什么都不做强。

换个角度看问题。当你开启一个问题单你要心里有谱。这个项目是有地方有问题的。这是你报告问题的原因。如果其他人都没动代码你就关掉问题，几天或者几年之后会有同样的问题出现。为了避免以后出问题，即使你提出来的可能不是问题，你也需要提出问题哪怕让开发人员加几条注释也是值得推行的。

4.避免噪音--记着加注释

每次提问题的时候都要指定一个问题解决人。不然即使你想表达自己想发而提出问题，也会是噪音。记住一个问题是两个人的事情。一个报告问题一个解决问题。像“我们试试另一种方法”或者“我记着之前出现过类似问题”是无用的。诚实的说出来，没人关系更多选择。我们需要的只是问题的解决方案。

如果你觉得问题的解决方案足够好，你可以给解决方案评论中写道“hi， 杰夫你的方法很好，因为......"这样可以帮助开发者关闭问题继续正常工作。

如果你觉得解决方案是错的，你可以对开发人员说“hi ，杰夫。我觉得你的方案不够好，因为......”这样你可以让开发人员指导问题的所在，在找到解决方案之前保证问题单是开放的。

还有，不要提出各种选择来干扰大家。而是专注。你或者赞同解决方案，关闭问题单或者不认同，继续开启问题单。在解决问题和保持问题中间徘徊一点也不会帮助项目的进行。

5.有问题就要提出来

很明显，但是我要重申：每个问题都必须可以重现。每次报问题你都需要解释运行过程中问题是如何出现的。是的，你的工作就是要证明软件并没有按照预期的运行，或者没有良好的手册支持或者不能满足现有需求等等。

每个问题提出者都需要遵循类似的规则：这是我们的现状，这是我们应该做的。所以修复一下吧。每个漏洞，直接说是个bug吧，一项任务，一个问题，一个解决方案，都应该这么标准化。提出问题的过程中，你想让项目从A点进行到B点。A点有些问题，而B点对于所有人来说会更好，所以你必须要向大家解释明白A点和B点各自是什么。最好可以解释清楚如何做，如果重现问题如何解决问题。

如果你有问题，你也需要遵循以下的格式：如果有问题，那么意味着项目的文档不足以支持你解决你的问题。这就是为什么出问题。所以你需要解决问题。所以问为什么使用X类不如问我觉得文档不够全面，因为没有解释清楚为什么使用X类。所以请修复。

如果你解释不清楚怎么解决问题，可以这样说：看上去这个类运行的不太正常。但是我不知道如何复现问题，如何解决问题。这会清楚地告诉大家你的问题报告不是很完善。问题解决者会首先了解问题，找方法重现问题。如果问题不能重新啊你的问题就不得不关闭了。

让我再重申一遍：每个问题都会把项目从A点带向B点。去B点的过程中如果有问题，那么就要解决问题。作为测试人员，你的职责就是画一条清晰的A点到B点的线路。

原文地址：http://www.yegor256.com/2014/11/24/principles-of-bug-tracking.html