6年前，我在一家中型跨国公司工作的时候，我建议与其浪费时间在准备充分的测试用例，还不如编写描述测试场景的文档。所有的人都对我的建议。投以烦恼的目光。他们的脸上清晰地传递出，我这个建议犯了个大错误。虽然没人否认了这一想法，但更没有人愿意接受。每个人都认同传统做法，即编写测试用例，会更稳妥。我无力反驳。
　　4年之后，该公司接到一个测试项目，的约束是时间，的期望是完整的测试证明材料。再次见面，我们讨论了怎么赶上后期限的想法。应用程序主要是关于“通过搜索和生成不同菜单项的报表”。编写和记录测试用例应该要花大部分时间，我们不确定，有多少文档会用到客户交付时。所以，我建议记录测试场景，虽然有些犹豫，但后大家都还是同意了。相对说我们可以节省宝贵的文档时间，更可以利用它进行测试。
　　测试用例很快会被测试场景代替吗？
　　随着时间的推移，一切都在变化，软件行业和过程也发生了深刻的变化。
　　传统的瀑布式和v-模型已经被敏捷和迭代模型所取代。文档是必要的，但是为了赶上后期限，使过程简单而透明的，文档的方式也是可以改变的。
　　这些时候测试用例的文档是很重要的:
　　1.客户要求的文档（是项目的一部分）
　　2.没有时间的约束(我不认为这是可能的)
　　3.测试员是新人的或不熟悉产品
　　4.公司政策(我坚信它可以改变)
　　让我分享一下我的一个经历
　　我和我的团队参与测试一个项目是世界500强公司，有着灵活的时间表。我们用好的模板来记录测试用例并且得到客户的评审通过。一旦开始组建QA团队，每天的大部分时间里，我们的责任是，机械地遵循100个测试用例，更新文档中通过/失败结果，和在结束的时候把结果发给客户。很多团队的成员开始抱怨工作的单调乏味，尽管这仍然可以为公司创收。
　　然后可以休息，没有新的测试。我们坐在一起，并讨论我们接下来要做什么。当我提议去想更多的方法来改进测试用例文档，所有的团队成员都否认我们投入的努力。按照他们的想法，他们没有更多地去思考我们已经覆盖的所有场景。说服他们跳出思维框架，产生更多的想法真的很艰难。
　　大多数时候，当我们测试用例(带执行结果)文档时，一旦得到客户的评审通过，认为我们所做的工作已经完成，我们的大脑会自动停止思考任何其他方法来测试产品。
　　相信我，当测试用例文档准备好了，我们只想机械地跟随它。请告诉我，在你的职业生涯中，你和团队成员在得到类似评审通过后，还提供了额外的测试用例的情况，你经历了过多少次?
　　另一个经历
　　在每周的团队挑战活动中，我们会要求团队成员完成对被测应用程序指定的“测试场景”。所有的团队成员，包括那些后期有反馈或无反馈的想法（有的没的的想法）。为什么呢?没有正式的用例文档了，他们不得不“诸如：补填预期结果，每个步骤的每个用例的功能和前提条件等等”。我们在中居然收集了40个测试场景，这是一个成功的经历。
　　为了更好地证明我的经验，我想展示一个例子。
　　拿一个应用程序做示例：用一个用户名、密码，登录和取消按钮的登录页面来说。如果以同样的要求写测试用例，我们将通过结合不同的选项和细节，的排列组合终可以写得50多个测试用例。