敏捷测试之_迭代开始.pptVIP

*;;; ; 我们在本书中始终强调，最好通过举例子的方式来帮助团队理解每个故事，并把这些示例写成测试用例来驱动开发。按照故事的优先级为他们排序。 故事应该事先经过评估，以保证每个故事能在几天之内完成。如果我们每隔几天就能拿到可测试的小故事，我们肯定不会把它们压到迭代末期才去完成。 敏捷测试人员以及其他团队成员们都应该警惕“范围扩展”的趋势。如果发现一个故事好像越做越复杂了，无需犹豫，赶紧两处红牌警告。Uesr story中的Lisa的团队总是特意找出那些华而不实的或者“最好有”的组件，因为他们并非故事的核心功能。这类功能可以最后再做，如果该故事的实际开发时间比计划时间长，他们也可以暂时不做。; ;17.1.3 书写任务卡片;17.1.4 确定工作量 身为一名测试人员，我们的职责是保证有足够的测试时间，而且还要不断提醒团队测试???质量是整个团队共同的责任。当团队要决定在迭代中可以交付多少故事时要明确其标准是：“我们能够完成多少编码和测试工作？”。有时候有些故事的代码编写十分简单，但是测试却是很复杂需要花费很多的时间。作为测试人员，要记住重要的是你只能同意将能够完成测试的故事加入到迭代中。如果必须要对迭代中交付的故事作出承诺，就应该作出保守的承诺。;17.2 可测试故事;17.3 与客户协作;17.4 高层次测试和事例;;17.4.2 与开发人员一起审查 与开发人员坐下来审查高层次测试和需求，如果与你工作的同仁在外地，想办法安排电话会议沟通。如果团队成员难以理解高层次测试和需求，下次就尝试别的办法。 具备良好领域知识的RD能够理解故事并在高层次测试编写前开始编码。即便是这样，最好还是与开发人员从客户和测试人员的角度审查故事。他们对故事的理解可能与你不同，请关注这种区别。测试用例有助于把故事置于应用其余部分的环境中。开发人员可以利用测试帮助他们正确编码。所以才要尽可能在迭代一开始就编写测试——RD开始编码之前。 我们通常会询问RD:我们遗漏了什么（Edit case）？代码的高风险区域是什么？他们认为测试应该关注哪些地方？获得更多技术观点有助于设计详细的测试用例。;;