00.测试两个流程：将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面；将测试要点变成全面的测试，这些测试可以用来演示故事已正确、完整地实现。
01.故事编写代码钱就开始制定验收测试
*开发人员和客户讨论故事且需要记录明确的细节时
*在迭代开始时，在写代码钱作为一项专门的任务
*在开发中火之后的任何时候发现新的测试时
02.测试问题：
*关于这个故事，程序员还需要知道什么？
*对怎么实现这个故事，我的想法是什么？
*有没有一些特殊情况会使这个故事有不一样的行为？
*这个故事在什么情况会出错
03.客户定义测试
既然软件是用来实现用户的愿景，验收测试当然就应当有客户来定义。客户可以和程序员与测试人员合作创建测试，但是客户至少应该给我们详细指出一些测试，用以验证故事的实现是正确的。
04.测试是开发过程中一部分，而不是在编码完成后要做的事，这点对使用用户故事非常重要。产品经理和测试人员共同负责列出详细的测试。产品经理带来驱动项目的公司目标的知识；测试人员则带来怀疑的心态。
05.一个优秀的开发团队会为很多详细的用例写单元测试。客户不负责定义所有可能的测试。客户应该更专注于那些能像开发团队说明故事意图的测试。
06.故事测试主要是功能性测试，用来确定应用程序是如期运行
*用户交互测试，确保所有用户交互组件如期工作
*可用性测试，确保程序好用
*性能测试，测量应用程序在个负荷下的工作状况
*压力测试，使应用程序用户和事物的基线值情况或其他任何让应用程序处在压力下的情况下运行
07.测试的是缺陷，而不是覆盖率
08.在一个敏捷的由故事驱动的项目中，测试并不像很多团队那样是一个对抗性的活动。发现缺陷，不该有被我逮到了吧这样的心态。在敏捷开发中，若有缺陷直到系统投产的时候才被发现，团队成员是不应该互相推卸责任的。高度写作的团队以及“我们共同负责”的心态能防范这种事情的发生。