3.2.1 寻找隐藏的假设

　　正如前文所述，开发人员通常关注一些重要的系统功能而忽视细节。此外，敏捷开发倡导简单的实现方案，每个开发 Sprint 周期不可能将功能完美得实现；相反，每个 Sprint 都会增量得开发一些功能。所以，测试人员在初需要从各种角度来寻找系统需求，探索隐藏的假设。

　　项目实例：

　　1. 从在线 B2B 公司角度思考

　　Q：这个搜索框对公司的业务有什么价值？

　　A：搜索框可以为用户方便得提供商户的目录信息。如果越来越多用户使用这个搜索框，可以增加我们网站的访问量。

　　2. 从用户角度思考

　　Q：作为查询信息、寻找商业合作伙伴的网站用户，搜索框对我有什么好处？

　　A：坏处：找到一家商户的地址，过去才发现已经关门歇业

　　好处：查找商户很简单，只要轻点鼠标

　　不快：有时候在寻找一类商户，却记不清楚具体名字

　　3. 从程序员角度思考

　　Q：一个搜索框的简单实现方法是什么？

　　A：一个有 text input 和 search button 组成的 form；后台通过 server 程序将符合类型和地址的商户名从数据库中取出，返回给用户；每个返回项包括商户的名称、地址和评价意见。

　　4. 寻找这些观点中的问题

　　Q：搜索框如何在用户忘记具体名字的时候提醒用户？

　　A：在第一版本中实现比较困难。可以让用户输入至少一个类型来提高模糊查找的效果。

　　5. 后寻找到隐藏的假设

　　以上的思考让测试人员对系统的隐含假设更加清晰：

　　首先，系统应该能够在高峰时候处理 200 条搜索请求和 1000 个鼠标点击事件。

　　其次，用户可以在已经查找到的内容中继续查找

　　后，系统提供一个商户类别清单；如果用户选择商户类别而忘记具体名字，系统提供模糊查询。

　　在敏捷开发中，这些假设可以作为用户故事记录下来，从而指导未来系统的开发和测试。

　　3.2.2 设计概要的验收测试用例

　　定义完一系列用户故事后，测试人员可以着手设计概要的验收测试用例。正如我们在前文论述，不同于单元测试，验收测试检查系统是否满足客户的预期，也是用户故事是否能够实现。于是，测试人员可以根据每条用户故事来扩展，寻找其中的“动作”，然后为每条“动作”制定正例和反例。

　　项目实例：

动作                 数据                                             期待的结果
搜索    一组能成功搜索到的（类别，位置）数据        在该类别和位置条件下的一组商户信息
搜索    一组不能成功搜索到的（类别，位置）数据       空列表

　　3.3 迭代 Sprint 阶段

　　当一个 Sprint 周期正式开始时，项目经理将制定该周期的具体开发和测试任务。在定期的 Sprint 计划会议（Planning Meeting）上，每位团队成员都要提供自己在未来一个 Sprint 周期中的休假和培训计划。另外，每个团队可以根据各自团队成员的能力和工作经验，适当设定一个工作负载值（Load Factor）。比如，我们团队的工作负载值为 75%，也是说每个人平均每天工作 6 小时（以 8 小时计算）。接着，大家可以开始分配任务。

　　当开发团队开始编码和单元测试时，测试人员的工作重点包括：估算验收测试的时间、估算测试框架的搭建、详细设计验收测试和编写验收测试代码。第两个主要活动一般在项目初期的 Sprint 周期中完成。其他的三个主要活动将在接下来的多个 Sprint 周期中视情况迭代进行。下面我们将具体介绍每个主要活动。