每个迭代过程后需要进行验收测试。验收测试有两个流程：1、将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录下来；2、将测试要点变成全面的测试，这些测试用来演示故事已正确、完整地实现。而且故事卡上写有测试的一些内容会提醒程序员在实现的时候该注意什么，所以为了让程序员尽早了解测试的内容，应该在为这个故事编写代码前开始制定验收测试。测试应该由客户自己或客户与程序员和测试人员一起制定。为了测试更加的全面测试可分为一下几种类型：1、用户交互测试，确保所有用户交互组件如期工作；2、可用性测试，确保程序好用；3、性能测试，测量应用程序在各种负荷下的工作状况；4、压力测试，即测试应用程序的极限。
所谓测试即找出应用程序的缺陷而不是测试应用程序覆盖率，应注意测试的目的和侧重点即找出缺陷并消除缺陷。如果有需要，开发团队可以负责实现自动化验收测试，自动化验收测试可采用集成测试框架（FIT）。对于测试来说没有规定的次数，只要测试还在继续为故事增加价值和使它更加清晰，客户就应该继续写测试，并且测试应该在编码过程中进行而不是编码结束之后，所以在每一轮迭代开始阶段，应列出尽可能多的测试，方便其在进行过程中对软件进行测试。
接下来就是如何编写一个好的用户故事。要注意的是用户故事的形式是对话：首先要考虑每一个用户角色，了解用户使用软件的目的；其次每一个故事都是封闭的，即完成每个故事伴随着的是一个有意义的目标的实现，能让用户使用时感受到他完成了某个任务；然后可以用约束卡来适当提醒；再然后是根据实现时间来确定故事的规模，适当调整其精确度；还有就是最好不要过早的设计用户界面，因为界面和实现的功能之间也有一定的联系，过早的设计出来，最后可能会有较大改动；每个故事最好只为一个用户编写从而增强其可读性。每个故事要让客户尽量使用简短干练的主动语态来描述功能。因为故事卡主要目的是用来提醒开发人员和客户团队对功能进行讨论的，所以要尽量简洁，可以适当加入细节，但是细节不可过多以至于取代对话。而且尽量不要给故事卡编号，因为将其分配到迭代过程时，如果每个故事有编号会带来一些不必要的麻烦。
所以每个好的故事卡都是简洁明了的对话组成的；不需要很详细主要起到一个提醒的作用，上面所写的测试部分相对于要实现的功能来说也尤为重要，可以提醒开发人员在编程过程中要注意什么。所以每个迭代对应的故事卡都有其相应要测试的内容，而测试的内容要提前编写，方便开发人员对编程侧重点的把握。