敏捷测试之-迭代开始

17.1.3 书写任务卡片
在整个团队都对故事有了清晰的了敏捷开发方式通过测试来驱动编码，我们同时编写测试和开发 任务卡片。 有的团队喜欢把测试任务直接写在其开发任务的卡片上。这是种简单的 解决方法，因为很显然一个开发任务只有当它通过了测试之后才能算是“已 完成”。这种做法可以避免形成“小瀑布”的趋势，也就是把测试留在最后 来做，这通常会让RD觉得既然这个故事已经提交给了QA，它就已经完成了。 总之，选择一种适合你们团队的任务卡片编写的方式即可。 在写开发任务卡片时，要保证编码任务的评估值包括了写单元测试和程序 员要做的其它测试时间。测试人员有责任确保每张卡片的估计值都是合理的 。如果估计值的误差达到2倍以上，那么有必要进行再次讨论并重新估值。 测试数据是评估测试任务时需要考虑的另一个事项。所以获取测试数据所 花费的时间也应该考虑到评估时间里。
然，这个产品会很不完善，会有很多功能还没有添加进去，bug很多，还不稳定，但客户看了以
后，会提出更详细的修改意见，这样，你就知道自己距离客户的需求有多远，我回家以后，再花 一个月，在上个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出 一个更完善的产品来，给客户看，让他们提意见。就这样，我的产品在功能上、质量上都能够逐 渐逼近客户的要求，不会出现我花了大量心血后，直到最后发布之时才发现根本不是客户要的东 西的情况。 缺陷：那就是周期长、成本很高。
第十七章 迭代开始
Owen
1
为什么要开始迭代
迭代模型是RUP（Rational Unified Process，统一软件开发过程)推荐的周期模型。 迭代是循环，往复 反馈的一个过程。 理解：我们大家可以这样想：我们开发一个产品，如果不太复杂，会采用瀑布模型，这样几个月过去 了，直到最后一天发布时，大家可以见到一个完整的产品。这种模型周期相对短些，成本相对低 些。但这样的方式有明显的缺点，假如我们对用户的需求判断的不是很准确时，你工作了几个月 甚至是几年，当你把产品拿给客户看时，客户往往会大吃一惊，这就是我要的东西吗？ 如果采用迭代模型：假如这个产品要求6个月交货，我在第一个月就会拿出一个产品来，当
我们今天的分享就到这里， 谢谢大家
3，与客户协作
4，高层次测试和事例
与开发人员一起审查
测试用例作为文档
17.1 迭代计划
17.1.1 了解细节
理想情况下，产品负责人或者客户团队的其它成员 参加迭代计划会议，回答大家的问题，并且提供示例来 描述每个故事的需求。如果业务方面的人都无法参加， 那么团队中工作与客户紧密相关的成员们可以充当客户
17.4.1
与客户一起审查 持续与客户保持协作关系是非常重要的。与客 户审查高层次测试是加强协作与沟通的好机会，特 别是对新的敏捷团队来说，在团队中习惯了不断讨 论故事，需求和测试用例之后，可能不需要坐下来 回顾每一个测试用例。 如果团队通过合同开发软件，需求和测试用例 可能是必须提供的东西。即使不是，最好通过客户 易于自己理解的形式提供测试用例。
17.3
与客户协作
与客户或者客户代表（如功能测试人 员）紧密合作是敏捷测试人员最重要的工作 之一。当启动迭代时，客户协作也进入了更 高阶段。此时，请求客户提供更高的示例， 在白板上讨论，然后将这些示例转化为驱动 编码的测试。 即使产品负责人和其他客户 在迭代规划期间和之前解释说明了故事，有 时在迭代开始时简要温习一下也是有帮助的 。不是所有人之前都听到过，再之客户可能 还有更多的信息。
17.1.2 考虑所有的观点
作为测试人员，需要从整体的角度考虑每个故事对系统其它部分可能的潜在影响。 就像 在产品发布计划会议中那样，站在不同角色立场考虑问题——用户，利益相关者，程
序员，技术文档编写者以及每个参与开发功能的人员。
User story： 在迭代计划会议中讨论为某个Web添加新图片，这是大家的讨论记录： PM：“我们来谈谈那个添加图片的故事吧” RD1: “大家觉得完成它需要多长时间？”（时间）
优势：在应付大项目、高风险项目时——就比如是航天飞机的控制系统时，迭代的成本比项目失败
的风险成本低得多（降低项目风险低，成功率高，特别是大型项目），用这种方式明显有优势。
敏捷测试人员在迭代开始时的活动？ 了解细节 考虑所有观点 1，迭代计划
书写任务卡片
确定工作量
迭代的 开始
2，可测试的故事
与客户一起审查
17.4.3 测试用例作为文档 高层次测试用例，加上在迭代期间编写的可执 行测试，将成为应用文档的核心。需求会在迭代中 或迭代后发生变化，所以请确保可执行测试用例易 于维护。不熟悉敏捷开发的人误以为没有文档，实 际上，敏捷项目生产了包括可执行测试的可用文档 并不断更新。 把可执行测试作为需求文档组成部分的好处在 于避免了争论。
RD2：“很快，可能半天就差不多了” RD3：“那么数据库的变动呢” （数据库） RD2：“我已经计算在 里边了” RD1：“那好半天” RD4：“等等，上个迭代里我们发现了几个性能方面的问题，如果我们 再添加照片，性能就更差了” （性能，联动因素）RD1：“好吧，看来我们得慎重考虑这个问题了，还 有其它方法吗？”RD2：“我建议我们可以做个快速的尝试，添加些图片再做一遍性能测试如何？”（ 好的建议） 会议总结：在故事开始之前，我们做这样一次讨论，让我们搞清楚了我们可能会遇到的问题，这种情形很 不错。如果不太确定某个故事会对系统其它部分产生什么影响，或者不了解开发某个功能的难度，都可 以并且应该在迭代计划阶段提出来，尽早暴漏不确定因素，为之做更多的研究或尝试以获得更多的信息 。基于不同的视角来提问有助于明了故事地方主旨，并且能让团队的工作更有成效。
17.4
高层次测试和事例
我们需要“全局性”的测试来帮助开发人员确保故事的正 确方向。通常，我们建议从示例开始，然后将其转化为测试。 高层次测试应该表现故事背后的主要意图。它们可能包括 预期和非预期行为的示例。 分布式团队（不在同一区域）需要通过电子网络方式获得 高层次的测试，而在同一区域工作的团队可以通过在白板上画 画来合作，甚至与客户坐在一起，在编码时告诉他们的需求 在迭代启动时，要注意快速了解每一个故事的基本需求， 并在适合团队的情境中表述出来。大多数敏捷团队的最大问题 是如何充分理解每个故事一准确发布客户所需的东西。他们的 代码可能没有缺陷，但是也许不完全符合客户的预期功能，或 者在客户不断澄清自己的需求时，他们在迭代时不得不重复大 量工作，并最终导致消耗了时间而无法按时完成故事。
17.2
可测试故事
当你研究故事而开发人员开始思考如何实现它们时 ，请始终考虑如何测试它们。即故事具有可测试性。 User story： 当团队正在重写多步过程的第一步时，令人意外的 是，当开始编写新步骤时，过程的其它步骤都失败了， 除非第一步完整的实现了，否则迭代中的任何改变都无 法测试（说明此故事不具有可测试性）。在计划故事时 没有考虑可测试性。导致了这样的问题。在下一次发布 时，他们吸取了之前的教训，RD在页面上创建了一个额 外的按钮，允许测试人员选择要么调用新页面或者旧页 面以测试其它故事。如果不知道怎么测试某个故事的可 测试性，请在迭代计划会中提出来。
的代理，比如分析师。 他们会在迭代会议上解释故事的
细节，并从客户的角度做决策，或者简单的记录大家的 问题以便依次快速回答。
我们在本书中始终强调，最好通过举例子的方式来帮 助团队理解每个故事，并把这些示例写成测试用例来驱 动开发。按照故事的优先级为他们排序。 故事应该事先经过评估，以保证每个故事能在几天 之内完成。如果我们每隔几天就能拿到可测试的小故事 ，我们肯定不会把它们压到迭代末期才去完成。 敏捷测试人员以及其他团队成员们都应该警惕“范 围扩展”的趋势。如果发现一个故事好像越做越复杂了 ，无需犹豫，赶紧两处红牌警告。Uesr story中的Lisa 的团队总是特意找出那些华而不实的或者“最好有”的 组件，因为他们并非故事的核心功能。这类功能可以最 后再做，如果该故事的实际开发时间比计划时间长，他 们也可以暂时不做。
17.4.2
与开发人员一起审查
与开发人员坐下来审查高层次测试和需求，如果与你工 作的同仁在外地，想办法安排电话会议沟通。如果团队成员 难以理解高层次测试和需求，下次就尝试别的办法。 具备良好领域知识的RD能够理解故事并在高层次测试编 写前开始编码。即便是这样，最好还是与开发人员从客户和 测试人员的角度审查故事。他们对故事的理解可能与你不同 ，请关注这种区别。测试用例有助于把故事置于应用其余部 分的环境中。开发人员可以利用测试帮助他们正确编码。所 以才要尽可能在迭代一开始就编写测试——RD开始编码之前 。 我们通常会询问RD:我们遗漏了什么（Edit case）？代码 的高风险区域是什么？他们认为测试应该关注哪些地方？获 得更多技术观点有助于设计详细的测试用例。
17.1.4 确定工作量 身为一名测试人员，我们的职责是保证有足够的测试 时间，而且还要不断提醒团队测试和质量是整个团队共 同的责任。当团队要决定在迭代中可以交付多少故事时 要明确其标准是：“我们能够完成多少编码和测试工 作？”。有时候有些故事的代码编写十分简单，但是测 试却是很复杂需要花费很多的时间。作为测试人员，要 记住重要的是你只能同意将能够完成测试的故事加入到 迭代中。如果必须要对迭代中交付的故事作出承诺，就 应该作出保守的承诺。