敏捷测试的那些事儿
敏捷社区的一些成员探讨了几种表述何如进行用户故事的验收测试的技术，以及测试整个主题的方法。
Charles Bradley介绍了几种不同的描述如何进行用户故事验收测试的方法：
列举要点(Bullet points)
在一个用户故事卡片或者wiki上，以列举要点的形式，把对系统行为的期望结果和实际结果记录下来。这种技术适用于较小的或者简单的用户故事。
测试场景/数据……
把你测试需要用到的任何场景、数据都记录下来。比如，用正确的/错误的/空的密码来测试密码功能。跟之前的方法一样，这种技术通常非常适用于小的或者简单的用户故事。
先测起来
先进行一些测试，再洋洋洒洒把你需要验证的系统功能记录下来。这是一种比较易学的技术。这种方法适用于简单的测试，也是其他方法不适用时的万能钥匙。
Given/When/Then
使用三段式：Given，When，Then。在Given部分，罗列出前提条件，测试环境，测试输入以及系统状态。在When部分，则列出一些触发点或者状态转换事件。在Then部分，记录系统行为，期望的输出，或者下一个系统状态。这种技术对于有着很多前提条件或者有特定触发点的测试非常适用。
概念形态上的，带有实例的规格说明书(Specification By Example-Conceptual Form)
编制一张表格，包含测试输入和期望输出。所谓概念形态，就是不以特定的值来描述数据。如果能比较容易地做出这张表格，那么使用这种方法就很可能非常有效。
互相搭配
选择多种不同的方法应对不同的测试角度。
Peter Stevens则提出一个名为“如何演示”的测试表单。这个表单本质上是一个简单的流程，描述了如何向产品负责人演示完整的用户故事。他写道：
编制“如何演示”表单是梳理产品待办事项表的一部分，也就是说，这项工作可以在估算/交付计划会议的时候进行，可以安排在首轮Sprint计划会议的时候，也可以在项目的任何时候。它是会话交互的一部分，所以最好别定太早。
Lisa Crispin介绍了采用一张思维图来规划测试，以明确要完成的整个主题。团队用了五轮迭代来完成她所指的主题，也就是十周的工作量。Crispin和另一个测试人员一起着手测试，在一块白板上画出了要完成测试工作的思维图。接下来，他们和开发团队、产品负责人、管理者以及其他利益关系人讨论了思维图。
在主题的实现过程中，测试人员常常会参照他们的思维图。Crispin写道：
最终，我们信心满满，我们已经从所有角度想过并讨论过流程以及它对系统其它部分的潜在影响，我们还和所有利益关系人都聊了他们各自的要求和担忧，同时，不止从功能层面，还包括性能和可用性层面，我们都做了充足的测试。
