结果：崩溃

马虎的（有很大空间让人产生误解的）：

使数据库服务器脱机，保存，然后退出，崩溃了。

太多冗余的信息（不能够指出什么是引发错误的关键原因）

1．运行客户端

2．为输入新的条目查询数据库

3．打开一个浏览器

4．在yahoo.com上浏览新闻

5．关闭浏览器

6．选择一个条目

7．把种类从“蔬菜” 更改到“水果”

8．使数据库服务器脱机

9．尝试保存记录

10．收到一个超时的错误

11．退出客户端

结果：崩溃

在这个例子中，测试人员记录在发现错误之前他所作的一切，但是他没有检查是不是每个步骤都是必要的，例如从yahoo.com阅读新闻。

如果你只写下那些产生错误必不可少的步骤，开发人员将很少告诉你他们不能够重现错误，同样错误什么委员会也会很少决定“没有人将会做到那个程度！”

但是如果每个步骤都是必须的，怎么办呢？如果错误只在你执行了一些看上去没有关系的步骤后出现了，那么在bug report中记录下这些步骤。你可以在那些看上去没有逻辑关系的步骤后写上“必须的步骤”，或者你可以在bug report的开始部分加上注释：“注意－这里的每一个步骤都是重现错误的必要步骤。

编写清晰的步骤同样可以在验证修复过程中提供帮助，特别是在另一个测试人员做验证的时候。

解释错误的影响，不只是症状
一些bug report是令人误解的。从错误的表层看是无伤大雅的，但是如果在你检查错误的牵连时，你发现它是一个非常严重的问题。如果你在错误审核委员会，你会拥护先修改哪一个错误呢？

1．关于“一个令人讨厌的对话框阻止关闭应用程序”的报告

2．关于“在退出时应用程序中止了” 的报告