同样，如果你能使 bug 重现，而程序员不能，那很可能程序运行的各自环境（如计算机配置、已安装的软件等）是不同的，这种不同引起了问题。
程序员想要了解任何与你发现的问题相关的事情。有可能的话，到另一台机器上试试，多试几次，两次，三次，看看问题是不是经常发生。如果问题出现在一系列操作之后，不是想让它出现它就会出现，这就有可能是长时间的运行或处理大文件所导致的错误。程序崩溃的时候，要尽可能的记住都做了些什么。
最重要的是：程序员想要确定他们正在处理的是一个真正的「间歇性错误」呢，还是一个在另一类特定的计算机上才出现的错误。他们想知道有关你计算机的许多细节，如程序的版本、操作系统的版本......
小结：
bug 报告的首要目的是让程序员亲眼见到错误。如果你不能当面给他们演示，给出详细的复现步骤。
如果首要目的不能达成，程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了。详细的描述每一件事情：你看到了什么，你期望看到什么，把错误消息记下来，尤其是「错误日志]。
当你的计算机做了什么你料想不到的事，不要动！在你平静下来之前什么都别做。不要做你认为不安全的事。
尽量试着自己「诊断」程序出错的原因，即使做出了「诊断」，你仍然应该报告「症状」。
如果程序员需要，请准备好额外的信息。如果他们不需要，就不会问你要。他们不会故意为难你。你手头上一定要有程序的版本号，它很可必要信息。
详细。信息宁多毋少！如果你说了很多，程序员可以略去一部分，可是如果你说的太少，他们就不得不回过头再去问你一些问题。
慎用代词。诸如「它」、「窗体」这些词，当它们指代不清晰的时候不要用。
检查。重新读一遍你写的bug报告，你觉得它是否清晰？如果你列出了一系列能导致程序出错的操作，那么照着做一遍，看看你是否漏写了一步。
总的来说，最重要的是要做到精确、表述清楚，确保你的意思不能被曲解。如果做相同的事情有两种方法，请说明你用的是哪一种。