良好的BUG报告可以为您节省宝贵的时间

一份糟糕的BUG记录不仅烦人，而且大大增加了时间长的开销。为你的下一份BUG报考增加更多更详细的信息，可以使你更快速的定位BUG从而节省时间成本。

介绍
我想一份糟糕的BUG报告和很多人都有着或多或少的关联. 或是客户支持的工作人员. 用户的反馈报告、开发人员、测试人员或一级技术支持. 一份糟糕的BUG报告给他们带来时间上的开销. 除了一些（大多数）开源项目，人们花费了宝贵时间，但是这也意味着他们花费了金钱。

我将通过这篇文章告诉你一份糟糕的BUG报告怎样浪费你宝贵的时间和金钱的，同时也会告诉你如何才能做的更好. 下面开始从一个简短的解释来告诉你们一份糟糕的BUG报告到底长什么样子。

糟糕的BUG报告是什么样子的?
当我想到糟糕BUG报告的时候，我的脑海里它是这样的:

“我试着执行 sendMsg(“hello world!”)但是没有成功.”

相当不错的一个例子对吧? 这个报告只告诉我们它无法正常执行工作，但是并没有告诉我们任何其他详细的信息, 开发人员会打开程序的一部分代码检查，我保证大部分都会正常的工作。所以，什么样的BUG报告才算是标准的呢？ 这里有几个例子，我认为是比较重要。

缺少细节 就想上面的例子当中，你很难去发现到底哪里出现了错误，因为这份BUG报告没有提供任何细节。
且少日志/错误消息 错误消息的出现, 日志的写入、但是不知为何有些人总是忘记把他们写出到BUG报告中去。
一份报告中多种BUG的组合 为此为曾花费了大量的时间. 人们找到各种各样的BUG 但是没有全部都写入到一份报告中去。
这里还有更多类似的情况，但是这些我认为是最重要的，下面我继续看看如果你提交这样的一份糟糕的BUG报告会有什么后果。

糟糕的BUG报告浪费时间和金钱
另外一个例子: 比如说你提交了一个联系人系统的一份很差的BUG报告：

“我尝试添加新的联系人，但是没有添加成功！”

现在在另外一边的票务系统会发生什么？ 其他人在他们的机器上执行同样的程序，设置添加联系人并且成功了。现在至少有两件事情会发生:

你肯定会马上把票据拿回来，然后客户会问你发生了什么？（至少我肯定会这么问你）
有人可能会尝试着寻找一切可能造成这个BUG报告的原因: 这个联系人不能被添加. 没人知道是不是哪里有错误消息, 或者根本没有执行. 或者这个BUG出现是因为点击了添加联系人的按钮又或者是保存数据的时候出错. 大多数情况这个人是没有办法找到原因的所在, 所以最终你只能拿回票据并且被不停的追问到底发生了什么.
退回发票继续时间的浪费
无论售后人员和技术支持作何反应都会加大时间的开销.首先有人需要对这个问题做基本的分析. 由于你没有提供详细的BUG描述，这会让他们只能猜想哪里出了问题. 技术支持会一直找问题的原因直到最终来问你。 也有可能他们会把这张票据直接给你，因为你没有提供任何可供参考的BUG描述。

不管怎样都会到你这里, 因为除了你没人直到发生这个BUG的原因，因此他们可能会让你对BUG增加一些更详细的解释 (他们为什么自己就不能搞定这个问题呢？你心里一定这么想) 时间一天一天的过去，就是因为你提交了一个这样糟糕的BUG报考. 但是你需要提供一些信息, 否则其他技术售后无法重现BUG，无所修复这个BUG. 那么你现在会怎么做呢？我想你应该会打开那个票务系统尝试在你的机器上操作，你猜怎么着？它很可能这次不会出任何问题. 就因为你没有对BUG做一个良好的处理，对软件公司造成了时间上的流失，时间就是金钱。

但是让我们假设一下你可以重现这个BUG, 你打开这个票务系统，这次你添加了一些对BUG的描述. 然后技术售后看到这个问题，但是这一次你提供了一些BUG描述，然后他们通过你你提供的错误报告极有可能马上就可以修复这个BUG. 但是大部分的时候他们还是无法修复这个BUG. 然后他们有找到你让你在编写代码的时候 写入更多对BUG的处理信息.然后没完没了 ….

时间就是金钱，不要浪费金钱。
这张票据来回折腾浪费了很多时间. 每当有一个技术售后的一个人拿到这样的一张有问题的票据, 他或者她每次都需要想办法重新BUG，找出问题。技术售后同时还有其他的事情需要做，原本他们可以一周做更多的事情，但是现在他们需要花更多的时间来处理票据的问题，对于软件公司来说，时间就是金钱，你就是在浪费公司的钱。

原文转自：http://www.zcfy.cc/article/save-time-and-money-by-writing-useful-bug-reports-4311.html