Defect Reporting (Section 2) --怎样使Defect Report更加Effective

                                                          怎样使Defect Report更加Effective

                                                                                        ----总结版

你有没有自己发现的 Defect被Developer视为Not a bug 而被 Reject的经历呢？你有没有碰到过你发现的一个非常严重的Defect被Defer到下一个版本才去修复的情况呢？

   

     有人会很郁闷 ,有的怀疑自己的能力了,有的去抱怨Developer不理解自己,甚至去怀疑整个Team的团队精神.其实怀疑自己的能力和抱怨别人都不是好的Action.我们为何不来检查一下自己的Defect Report的描述是否有问题呢?

   

       Defect report 的核心是对错误的描述。表格中是一个关于好和差的错误描述的例子。编写好的defect report是一种好的艺术形式。采用以下的10条技巧可以帮助你的小组提高编写defect report的质量：

　　1.组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问獾牡胤健?

　　2.重现Reproduce：测试人员在编写defect report之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写defect report之前反复尝试3次。

　　3.隔离Isolate：在尝试编写defect report之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。

　　4.归纳Generalize：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？

　　5.对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。

　　6.总结Summarize：在defect report的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。

　　7.精简Condense：在defect report的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是defect report的目标。

　　8.消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。

　　9.中立Neutralize：如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的defect report在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Defect report来描述事实。

　　10.检查Review：一旦测试人员感觉defect report是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可能提交最好的defect report。

 

GOOD

BAD

概要（ Summary ） Arial, Wingdings 和 Symbol 字体破坏了新文件 重现问题的步骤（ Steps to Reproduce ）： 1. 启动 SpeedyWriter 编辑器 , 接着创建了一个文件 . 2. 输入 4 行文字 , 每次重复输入 “The quick fox jumps over the lazy brown dog”, 3. 选中 4 行文字，点击字体的下拉菜单，选择 Arial. 4. 所有的文字转变成了控制字符，数字和其他一些二进制的数据 . 5. 尝试了 3 次，每次都可以重现这个问题。 隔离（ Isolation ） 这个问题是新出现在 build 1.1.018; 相同的测试用例是在 builds 1.1.007 (System Test entry) 和 1.1.017 中通过测试的 . 使用 Wingdings 和 Symbol 字体也可以重现这个问题，但 Times-Roman, Courier New 和 Webdings 字体都没有这个问题。 基于模糊的猜测，这个可能只是一个关于格式化的问题。保存此文件再关闭它，然后再打开文件，这个错误还是存在。 在转换字体之前保存文件，将不会产生这个错误。 在已经存在的文件里，不会产生这个错误。 这个错误只出现在 Windows98 平台下，在 Solaris, Mac 或其它地 Windows 平台下不出现这个问题。

在格式一些文字成 Arial 字体时，我创建的新文件中所有的内容被毁坏了。

 

     

小结 : 当你编写Defect Report时，记住你的听众(or观众)，按照上上面的10个技巧去优化你的Defect Report,它将会因为你努力而格外漂亮，并且有更多的错误被修复。最终将达到我们期望的结果---使错误在伤害用户之前得到修复。