Kiki的专栏-我译，我所爱

--- 原著Elisabeth Hendrickson《Writing Effective Bug Reports》---Kiki翻译于2005/6/2         你有没有为了要更多的信息而被返回bug report的经历呢？有没有碰到过你发现的一个非常严重的错误被推迟到下一个版本才去修复的情况呢？       你提交的每一个bug report都是和项目组就正在测试中的软件质量问题的一种书

这是它的一个功能! --- 原著Danny R. Faught 《But It’s a Feature!》---Kiki翻译于2005/6/2 Bug report应该推荐一个精确的期望结果如果在一开始你就不能成功的使软件行为发生改变，那么利用文档作为一种使bug report继续有效并且有可能改变开发人员情绪的方法集中精力在描述错误信息的词语和文档上。不一致的矛盾可能可以提供构思错误的线索 “当

前言在99年的Quality week上的一次演讲中，微软的一个测试经理，Roger Sherman指出了由于“不可重现”导致bug关闭的主要原因。这是一个非常可惜的情况，因为这样的bug report浪费了紧张的开发计划中的宝贵时间，增加了对产品质量完全是无关紧要的事情，同时导致了在开发人员和测试之间的挫败感和差的感觉。有时，bug report是由于短暂的或随机的事件，测试和开发之间不一致的工

【原创】Bug追踪过程中需要注意的问题        很多朋友都问我，为什么那么喜欢研究bug报告，其实个人一直觉得bug报告高于一切，它是测试人员价值的终极体现。也许是工作的性质，我经常将香港的同事和深圳同事做比较，发现他们一个优点特别值得我们学习：做什么事一般不会去衡量事情的最终利益，更多的是决定后考虑如何更好地把事情做好。        脚踏实地，希望我自己也能够这样努力下去。 

如何编写更佳的bug report --- Mihir Kamdar《How To Write Better Bug Reports》---Kiki翻译于2006/6/18 我们是否经常看到开发人员针对我们归档的bug report要求提供更多的信息？我们是否经常需要在bug report归档后花更多的时间去研究那个问题？我们是否经常从开发人员那里听到在他们那边难以重现bug并

从开发的角度看待bug在工作中，经常有同事问到某个问题是不是bug，该不该提交，而且疑惑为什么会引起这样的bug，尤其是刚进入测试行业的同事。这个问题最好的答案就是提交。我基本上碰到这种问题就是鼓励他们提交他们所疑惑和怀疑的问题，即使后来发现不是问题，留在bug库中对后来的同事都是一种学习（在此建议给于新同事先看看bug库中的bug，如果时间不够也要尽可能的看看非正常结束的bug，如wont

   BUG TAXONOMY AND STATISTICS by Boris Beizer,as amended[1] by Otto Vinter  Copyright Notice:This document is based1 on the “Bug Taxonomy and Statistics” Appendix, SOFTWARE TESTIN