《用户故事与敏捷方法》阅读笔记05

第六章用户故事验收测试
      在写代码之前验收测试可以为程序员提供很多编写程序的信息，让程序员考虑到更多的情况。写测试的时间一般为：①开发人员和客户讨论故事并且需要记录细节时②在迭代开始时，在写代码前作为一项专门的任务③在开发中或者之后的任何时候发现新的测试时。
　　验收测试由客户来定义，客户要给测试人员一些详细的测试，测试人员再另外定义一些测试。
　　测试是开发过程的一部分，不是在编码完成之后再做。一般产品经理和测试人员共同负责列出详细的测试。在一轮迭代开始阶段他们应该一起列出更多的测试。
　　只要写的测试在为故事增加价值和使它更加清晰，那么测试就应该继续编写。客户更专注于那些能向开发团队说明故事意图的测试。
集成测试框架。客户负责引领系统的开发，而验收测试则向客户演示软件是可接受的。客户要执行验收测试，至少每轮迭代测试一次。因为每轮迭代都有可能破坏可工作的代码，所以测试非常的重要。
测试类型有很多，对于大多数系统，故事测试主要是功能测试，其余的测试还有：用户交互测试，可用性测试，性能测试，压力测试。
第七章 优秀用户故事准则
　　在一个大型项目中，有时候确定用户故事让人无从下手，作者给出的方法是，考虑一个用户角色，了解用户使用我们软件的目的。
　　当面临一个大的故事时，通常有许多方法可以将它分解成较小的故事。许多开发人员首先想到的是技术分割，这种做法的缺陷是没有一个故事是单独对用户很有用的。一种更好的办法是换一种方式编写故事，每个故事都提供某种程度的完整的功能。就是封闭的故事。一个封闭的故事是指那种随着一个有意义的目标的实现而结束的故事，能让用户使用后觉得她完成了某个任务，这种封闭的每一个故事都是原来那个非封闭故事的一部分。使用完这些封闭故事之后，用户可能会有一种成就感。
　　对于一些必须遵守而不需要直接实现的故事，在其卡片上注明约束。它不需要做估算，也不会像其他卡片那样被安排到迭代中。它可以作为提醒，或者进行测试。
　　根据时间来确定故事大小，越是眼前的故事，估计的精确度越高。