重磅推荐
测试是敏捷开发的关键组成部分。敏捷方法的广泛应用使人们开始关注如何有效测试，同时敏捷项目改变了测试人员的角色。但是，测试人员的许多职责还是得到了不少误解，测试人员的真正职能是什么？敏捷团队真的需要具有QA背景的成员吗？“敏捷测试人员”到底意味着什么？ 业界经验*丰富的两位敏捷测试实践者和顾问Lisa Crispin和Janet Gregory在《敏捷软件测试：测试人员与敏捷团队的实践指南》中给出了这些问题和更多问题的答案。在《敏捷软件测试：测试人员与敏捷团队的实践指南》中，Crispin和Gregory定义了敏捷测试的概念，并通过来自现实敏捷团队的示例阐述测试人员的职责。她们讲述如何利用敏捷测试象限来识别需要哪些测试，谁来做，以及哪些工具有帮助。《敏捷软件测试：测试人员与敏捷团队的实践指南》从测试人员的角度记录了敏捷软件开发迭代的一个完整周期，并解释了敏捷测试的七大关键成功要素。
注：两款不同封面，随机发货。
【内容简介】
读者将从《敏捷软件测试：测试人员与敏捷团队的实践指南》中收获 测试人员如何参与敏捷开发 测试人员和QA经理如何适应敏捷团队 敏捷测试人员的招聘要求是什么 如何从传统模式迁移到敏捷模式 如何在短期迭代中完成测试任务 如何利用测试指导开发 如何克服困难实现测试自动化
【作者简介】
Lisa Crispin是一名敏捷测试实践者和教练。她专注于向测试人员和敏捷团队讲述测试人员如何创造价值并利用面向业务测试指导开发。她的使命是把敏捷的快乐带给软件测试领域，并把测试的快乐带给敏捷开发领域。Lisa在2000年*次加入敏捷团队，作为开发人员、分析人员、测试人员和质量保证主管工作了若干年。从2003年起，她成为ePlan Services公司ePlan Services团队的测试人员。她经常在北美和欧洲的会议上教授有关敏捷测试的课程。Lisa经常发表敏捷测试的文章，刊物包括Better Software magazine、IEEE Software和Methods and Tools。Lisa与Tip House合著了Testing Extreme Programming (Addison-Wesley, 2002)。Janet Gregory是DragonFire公司(致力于敏捷质量过程咨询和培训)的创始人。她希望帮助团队构建质量系统。在过去十年间，她作为教练和测试人员，把敏捷实践介绍到各种规模的公司。她关注于让业务客户和测试人员理解其在敏捷项目中的角色。Janet的编程背景使她能更好地与敏捷团队中的开发人员合作以实施新颖的敏捷测试自动化方案。Janet经常在敏捷和测试软件会议上发表演讲，也是北美敏捷测试社区的主要贡献者。
【目录】
目录第Ⅰ部分 简 介第1章 敏捷测试的定义 31.1 敏捷价值 31.2 “敏捷测试”意味着什么 41.3 敏捷团队中角色和活动的情境 61.4 敏捷测试有何不同 71.5 整体团队运作方式 111.6 小结 12第2章 敏捷测试人员的十条法则 152.1 敏捷测试人员的定义 152.2 敏捷测试思想 162.3 应用敏捷法则和价值 162.4 创造价值 232.5 小结 24第Ⅱ部分 组 织 挑 战第3章 文化挑战 273.1 组织文化 273.2 测试/质量保证团队成功适应敏捷的障碍 313.3 引入变化 353.4 管理层期望 363.5 改变并不容易 393.6 小结 40第4章 团队构成 414.1 团队结构 414.2 人员分布 444.3 人力资源 454.4 团队建设 474.5 小结 49第5章 迁移传统过程 515.1 寻找轻量级过程 515.2 度量标准 525.3 缺陷跟踪 555.4 测试计划 605.5 现有的过程和模型 615.6 小结 64第Ⅲ部分 敏捷测试象限第6章 测试的目的 676.1 敏捷测试象限 676.2 知道一个用户故事何时完成 726.3 管理技术债务 736.4 上下文环境中的测试 736.5 小结 74第7章 支持团队的面向技术测试 757.1 敏捷测试基础 757.2 为什么编写并运行这些测试 777.3 面向技术的测试在何处停止 827.4 如果团队不做这些测试怎么办 837.5 工具箱 847.6 小结 86第8章 支持团队的面向业务测试 898.1 通过面向业务测试驱动开发 898.2 需求困境 918.3 小增量 988.4 如何知道我们完成了 1008.5 小结 102第9章 面向业务测试工具包 1039.1 面向业务测试的工具策略 1039.2 激发示例和需求的工具 1049.3 基于示例自动化测试的工具 1119.4 编写测试的策略 1199.5 可测试性 1239.6 小结 125第10章 评价产品的面向业务测试 12710.1 象限三简介 12710.2 实例演示 12910.3 场景测试 12910.4 探索测试 13110.4.1 基于会话的测试 13510.4.2 自动化和探索测试 13610.4.3 探索测试人员 13610.5 可用性测试 13610.5.1 用户需求和角色测试 13610.5.2 导航 13710.5.3 研究竞争对手 13810.6 图形用户界面背后 13810.6.1 API测试 13810.6.2 Web服务 14010.7 测试文档和文件 14010.7.1 用户文档 14010.7.2 报告 14110.8 探索测试辅助工具 14210.8.1 测试设置 14310.8.2 生成测试数据 14410.8.3 监控工具 14410.8.4 模拟器 14410.8.5 仿真器 14410.9 小结 145第11章 利用面向技术的测试评价产品 14711.1 象限四简介 14711.2 谁应该做 14911.3 何时做 15011.4 ility测试 15111.4.1 安全性 15111.4.2 可维护性 15311.4.3 交互性 15411.4.4 兼容性 15511.4.5 可靠性 15511.4.6 可安装性 15611.4.7 ility小结 15711.5 性能、负载、压力以及可伸缩性测试 15711.5.1 可伸缩性 15711.5.2 性能与负载测试 15811.5.3 性能与负载测试工具 15811.5.4 基准 15911.5.5 测试环境 16011.5.6 内存管理 16011.6 小结 161第12章 测试象限总结 16312.1 回顾测试象限 16312.2 系统测试实例 16412.2.1 介绍该应用软件 16412.2.2 团队和工作流程 16512.3 测试驱动开发 16612.3.1 单元测试 16612.3.2 验收测试 16612.4 自动化测试 16612.4.1 自动化的功能测试结构 16712.4.2 Web服务 16812.4.3 嵌入式测试 16812.5 评判产品的面向业务测试 16912.5.1 探索性测试 16912.5.2 测试数据源 16912.5.3 端对端测试 16912.5.4 用户验收测试 17012.5.5 可靠性测试 17012.6 文档 17012.6.1 用文档记录测试代码 17012.6.2 汇报测试结果 17112.7 熟练运用测试象限 17212.8 小结 172第Ⅳ部分 自 动 化第13章 自动化的原因和障碍 17513.1 为什么要自动化 17513.1.1 手动测试需要太长的时间 17613.1.2 手动过程容易出错 17613.1.3 自动化让人们有时间做更有价值的工作 17713.1.4 自动化回归测试提供了安全网 17813.1.5 自动化测试较早并频繁地给出反馈 17913.1.6 驱动编码的测试和实例可以做更多事情 17913.1.7 测试是强大的文档 17913.1.8 投资回报率和回报 18013.2 自动化的障碍—— 妨碍自动化的因素 18013.2.1 Bret的列表 18013.2.2 我们的列表 18113.2.3 程序员的态度 ——“为什么要自动化” 18113.2.4 “痛苦的积累”(学习曲线) 18113.2.5 初始投入 18213.2.6 总是改变的代码 18313.2.7 遗留代码 18413.2.8 恐惧 18413.2.9 旧的习惯 18413.3 可以克服这些障碍吗 18413.4 小结 185第14章 敏捷测试自动化策略 18714.1 测试自动化的敏捷方法 18814.1.1 自动化测试的分类 18814.1.2 测试自动化金字塔 18914.2 哪些测试可以自动化 19114.2.1 持续集成、构建与部署 19214.2.2 单元与组件测试 19314.2.3 API或Web Services测试 19314.2.4 GUI底层的测试 19314.2.5 测试GUI 19314.2.6 负载测试 19414.2.7 比较 19414.2.8 重复的任务 19414.2.9 创建数据 19414.3 什么测试不应该自动化 19514.3.1 可用性测试 19514.3.2 探索性测试 19614.3.3 永远不会失败的测试 19614.3.4 一次性测试 19614.4 哪些测试不易于自动化 19714.5 从哪里开始自动化策略 19814.5.1 不愿自动化的原因 19814.5.2 多层方法 19914.5.3 思考测试设计与维护 20014.6 选择正确的工具 20114.7 将敏捷法则应用到测试自动化上 20414.7.1 保持简单 20414.7.2 迭代式反馈 20514.7.3 整体团队运作方案 20514.7.4 花时间做正确的事情 20714.7.5 边做边学 20814.7.6 将敏捷编码实践应用到测试上 20814.8 为测试提供数据 20914.8.1 数据生成工具 20914.8.2 避免访问数据库 21014.8.3 如果数据库访问不可避免或是必须要使用数据库 21114.8.4 明确所需 21314.9 评估自动化工具 21314.9.1 确定自动化工具的需求 21314.9.2 一次一个工具 21414.9.3 选择工具 21514.9.4 适用于敏捷的工具 21714.10 实现自动化 21714.11 管理自动化测试 21914.11.1 组织测试 21914.11.2 组织测试结果 22114.12 开始行动 22214.13 小结 222第Ⅴ部分 测试人员经历的一个迭代第15章 测试人员在发布或主题计划阶段的工作 22715.1 制定发布计划的目的 22715.2 故事评估 22915.2.1 如何评估故事 22915.2.2 测试人员在评估故事工作中的角色 23015.2.3 一个故事评估的实例 23115.3 设定优先级 23315.3.1 为什么要为故事设定优先级 23415.3.2 设定优先级时关于测试的注意事项 23415.4 开发的范围 23515.4.1 截止日期和时间表 23515.4.2 关注产品价值 23615.4.3 系统范围的影响 23615.4.4 第三方的介入 23815.5 制订测试计划 23815.5.1 从何处开始 23915.5.2 为什么要写测试计划 23915.5.3 测试的种类 23915.5.4 测试基础设施 24015.5.5 测试环境 24015.5.6 测试数据 24115.5.7 测试结果 24115.6 测试计划的可选形式 24215.6.1 轻量级测试计划 24215.6.2 使用测试矩阵 24315.6.3 测试表格 24515.6.4 白板 24515.6.5 自动化的测试列表 24515.7 准备可见性 24515.7.1 跟踪测试任务及其状态 24515.7.2 传达测试结果 24815.7.3 产品发布的关键 24815.7.4 已通过的测试数 24815.7.5 代码覆盖率 25015.7.6 缺陷度量 25215.8 小结 254第16章 迭代前的准备 25516.1 积极主动 25516.1.1 益处 25616.1.2 真的需要吗 25716.1.3 提前准备的潜在弱点 25816.2 事先明确 25816.2.1 客户意见一致 25816.2.2 用户故事的规模 25916.2.3 地域分散的团队 26016.3 实例 26116.4 测试策略 26316.5 确定缺陷的优先级 26416.6 资源 26416.7 小结 264第17章 迭代开始 26517.1 迭代计划 26517.1.1 了解细节 26617.1.2 考虑所有观点 26717.1.3 确定工作量 27217.2 可测试故事 27217.3 与客户协作 27417.4 高层次测试和示例 27517.4.1 与客户一起审查 27717.4.2 与开发人员一起审查 27717.4.3 测试用例作为文档 27817.5 小结 278第18章 编码和测试 27918.1 驱动开发 28018.1.1 从简单入手 28018.1.2 增加复杂度 28018.1.3 评估风险 28018.1.4 编码和测试同时进行 28218.1.5 识别变更 28218.1.6 三方协作的力量 28318.1.7 关注一个故事 28318.2 评判产品的测试 28418.3 与开发人员协作 28418.3.1 结对测试 28418.3.2 自我展示 28518.4 与客户交流 28518.4.1 展示给客户 28518.4.2 理解业务 28618.5 完成测试任务 28618.6 处理缺陷 28718.6.1 这是一个缺陷还是一项功能 28718.6.2 技术债务 28718.6.3 零缺陷容忍 28818.7 如何选择 28818.7.1 判断应该记录哪些缺陷 28918.7.2 何时修补缺陷 29018.7.3 选择记录缺陷的介质 29118.7.4 处理缺陷的方案和建议 29218.7.5 从简单入手 29418.8 促进沟通 29518.8.1 测试人员促进沟通 29518.8.2 分散式团队 29618.9 回归测试 29718.9.1 确保构建“通过” 29718.9.2 确保构建快速 29818.9.3 构建回归测试集 29818.9.4 注意“全局观” 29818.10 资源 29818.11 迭代度量 29918.11.1 度量进度 29918.11.2 缺陷度量 30018.12 小结 302第19章 迭代结束时的收尾工作 30319.1 迭代演示 30319.2 迭代回顾 30419.2.1 开始、停止、继续 30419.2.2 做出改进 30619.3 庆祝成功 30719.4 小结 309第20章 成功的交付 31120.1 产品的构成 31120.2 为测试计划足够的时间 31320.3 结束阶段 31320.3.1 测试候选发布构建 31420.3.2 在分期环境上测试 31420.3.3 *后的非功能测试 31520.3.4 与外部应用集成 31520.3.5 数据转换和数据库更新 31520.3.6 安装测试 31720.3.7 沟通 31720.3.8 如果没有准备好该怎么办 31820.4 客户测试 31920.4.1 UAT(用户验收测试) 31920.4.2 alpha/beta测试 32020.5 开发后的测试周期 32020.6 可交付的东西 32220.7 发布产品 32320.7.1 发布验收标准 32320.7.2 发布管理 32520.7.3 打包 32620.8 客户期望 32620.8.1 产品支持 32620.8.2 理解对业务的影响 32620.9 小结 327第Ⅵ部分 总 结第21章 关键成功要素 33121.1 成功要素之一：使用团队整体参与的方法 33121.2 成功要素之二：采用敏捷测试思维 33221.3 成功要素之三：自动化回归测试 33321.4 成功要素之四：提供并获取反馈 33321.5 成功因素之五：构建核心实践的基础 33421.5.1 持续集成 33421.5.2 测试环境 33521.5.3 管理技术债务 33521.5.4 增量工作 33521.5.5 编码和测试是同一个过程的组成部分 33621.5.6 实践之间的协作 33621.6 成功因素之六：与客户合作 33621.7 成功要素之七：保持大局观 33721.8 小结 337术 语 表 339参考文献 345
【前言】
我们是极限编程(XP)的早期实践者，在完全不了解测试人员应该如何工作的XP团队中从事测试工作。那时候，敏捷(当时还没有这个称谓)资料中对验收测试和专业测试人员的工作方式介绍得很少。我们通过自身的经验和小规模敏捷社区这两方面来学习。在2002年，Lisa和Tip House合著了《测试极限编程》，该书的出版得到了Janet的大力帮助。从那时起，敏捷开发模式开始演变，敏捷测试社区不断繁荣。在众人的群策群力下，我们对敏捷测试的学习更加深入。我们凭借个人和合作的力量帮助团队过渡到敏捷模式中，帮助测试人员了解如何在敏捷团队中贡献自己的力量，并与敏捷社区的其他成员紧密协作寻找让敏捷团队在测试方面更加成功的方法。我们两人的经历各异。Lisa作为一名敏捷测试人员在稳定的团队中工作了若干年，针对零售、电信和金融行业的Web应用。Janet则在软件公司中开发各个行业的企业系统。这些敏捷项目包括开发消息处理系统、环境跟踪系统、远程数据管理系统(包括嵌入式应用和交互网络)、石油天然气产品统计应用和飞机运输应用。她扮演过很多角色—— 有时是测试人员、有时是指导—— 但是她一直在努力使测试人员与团队的其他人更融洽。她参与团队的时间从六个月到一年半不等。因为存在不同的视角，我们学会了合作和互补各自的知识库，并一起做了许多演讲和共同编写了许多教材。《敏捷软件测试：测试人员与敏捷团队的实践指南》的由来目前，市面上已经出版了一些有关面向敏捷开发中的测试和测试模式的优秀书籍(见参考书目)。这些书一般关注于如何帮助开发人员。《敏捷软件测试：测试人员与敏捷团队的实践指南》的目的是在帮助敏捷团队通过业务人员能够理解的测试来更加有效地创造业务价值。我们想帮助测试人员和质量保证(QA)人员从传统的开发模式过渡到敏捷开发。在《敏捷软件测试：测试人员与敏捷团队的实践指南》中，我们将讲述如何通过实用、逐步的方式应用我们在不同团队中的经验成果和来自其他敏捷先驱的思想，帮助测试人员、质量保证经理、开发人员、开发经理、产品负责人和其他任何致力于敏捷项目高效测试的人员，交付客户所需的软件。但是，我们更关注测试人员这个角色，因为很多专业人员都会担当此任。敏捷测试实践不局限于敏捷团队成员。它们也可以用于传统开发模式项目的测试。我们希望能够帮助在任何开发模式下的测试人员。敏捷开发不是成功交付软件的*方式。但是，我们参与过的所有成功团队，不论是敏捷模式还是瀑布模式，都存在一些共性。其中包括，程序员编写和自动化单元测试和集成测试(覆盖多数代码)，严格使用源代码控制和代码集成系统。测试人员从开发周期一开始就参与工作，并拥有足够的时间和资源来完成所有类型测试的任务。定期运行和检查自动化的回归测试集(在高层次覆盖系统功能)。开发团队理解客户的工作和需求，与业务专家紧密合作。人是促使项目成功的关键，而不是开发模式或者工具。我们喜欢敏捷开发，因为它的价值、准则和核心实践能够让人出色地工作，测试和质量是敏捷开发的中心。《敏捷软件测试：测试人员与敏捷团队的实践指南》将讲述如何将敏捷价值和准则应用到自己的具体测试工作中，并使团队取得成功。第1章和第2章将详细讨论这个问题。编写《敏捷软件测试：测试人员与敏捷团队的实践指南》的方式因为体会到敏捷开发的益处，所以我们采用敏捷实践来编写《敏捷软件测试：测试人员与敏捷团队的实践指南》。在开始动工的时候，我们与世界各地的敏捷测试人员和团队讨论了他们遇到的问题和解决办法。然后，我们计划如何在《敏捷软件测试：测试人员与敏捷团队的实践指南》中包含这些内容。我们制订了一个两周一迭代的发布计划。每两周在我们的图书网站上发布两章草稿。因为我俩身处异地，所以要使用工具交流，并对各章实施“源代码控制”，向读者发布书稿，并获得反馈。我们无法实时地“结对工作”，但是各章会经过反复的审阅和修订，并通过即时消息进行非正式的“站立会议”。我们的“客户”就是敏捷社区中志愿审阅草稿的好心人。他们通过电子邮件或者亲自提供反馈。我们在随后的编写和修订中利用反馈作为指导。在所有草稿完成之后，我们针对修订做了新计划，其中包括了来自“客户”的所有积极的建议。*重要的工具是思维导图。首先创建了一张思维导图描述全书的构思。然后对每一章创建思维导图。在编写各章之前，我们基于思维导图展开头脑风暴。在修订的时候，重新查看思维导图，帮助我们发现可能遗失的想法。因为我们认为思维导图存在很大作用，所以在每章的开始部分包含了相应的思维导图。希望它们能够帮助你总览本章包含的所有信息，并鼓励你尝试使用思维导图。读者对象如果你曾经问过以下某个问题(我们已经听到过许多次)，那么《敏捷软件测试：测试人员与敏捷团队的实践指南》将对你有所帮助：● 如果开发人员编写测试，那么测试人员做什么？● 我是一名质量保证经理，公司正在实施敏捷开发(Scrum、XP、DSDM等)，我的职责是什么？● 我曾经在传统的瀑布式团队中做过测试人员，并且对敏捷非常感兴趣。我应该需要哪些知识来适应敏捷团队？● “敏捷测试人员”意味着什么？● 我是敏捷团队的开发人员，团队采用测试优先开发模式，但是客户仍然对我们交付的产品不满意。我们存在哪些缺陷？● 我在领导敏捷开发团队。质量保证团队无法跟上我们的速度，测试总是滞后。我们应该在开发的后一个迭代中测试吗？● 我是开发经理，*近转而采用敏捷开发，但是所有测试人员都离职了，为什么？● 我是测试人员，团队即将采用敏捷模式。我没有任何编程和自动化技能，在敏捷团队中还能立足吗？● 测试如何才能跟上两周一迭代的节奏？● 负载测试、性能测试、可用性测试等所有非功能性测试怎么办？如何在敏捷中实施？● 我们存在审计约束。敏捷开发和测试如何解决这些问题？如果你有类似的问题并且正在寻找切实可行的建议来指导测试人员如何帮助敏捷团队，以及敏捷团队如何有效地进行测试，那么这《敏捷软件测试：测试人员与敏捷团队的实践指南》正适合你。敏捷开发有许多“风格”，但是它们存在不少共性。正如在第1章所说的，我们支持敏捷宣言，不论你在实施Scrum、Extreme Programming、Crystal、DSDM，还是在实施自己的敏捷开发模式，都会在《敏捷软件测试：测试人员与敏捷团队的实践指南》中找到有助于测试的信息。敏捷测试书籍的用户故事当Robin Dymond(一位帮助许多团队实施精益和敏捷模式的管理顾问和指导)得知我们正在编写《敏捷软件测试：测试人员与敏捷团队的实践指南》时，给我们发来了他想要实现的用户故事，其中包含了许多我们计划满足的需求。 满足条件：● 消除害怕失去对测试控制的担忧。● 消除必须编写代码(以前从未做过)的担忧。● 作为测试人员，要了解对团队的新价值。● 作为初次接触敏捷的测试人员，要能够容易地理解新角色中*重要的事情。● 作为初次接触敏捷的测试人员，要能够容易地忽略新角色中不重要的事情。● 作为初次接触敏捷的测试人员，要能够容易地获得对自身情况非常重要的敏捷测试的更多细节。当我考虑问题解决方案时，我想到了Scrum和XP。通过Scrum你能够简单地了解如何使大家快速实施敏捷。但是，Scrum只是成功敏捷团队的冰山一角。对于初次接触敏捷的测试人员来说，应该通过分层的方式向他们展示敏捷测试思想。今天应该了解什么？明天应该了解什么？应该为持续改进考虑与情境相关的什么具体事情？我们努力在《敏捷软件测试：测试人员与敏捷团队的实践指南》中提供上述的细节，从全新的角度教授敏捷测试：过渡到敏捷开发、使用敏捷测试矩阵指导测试、解释在敏捷开发周期中发生的所有不同的测试活动。如何阅读《敏捷软件测试：测试人员与敏捷团队的实践指南》如果不知道如何阅读《敏捷软件测试：测试人员与敏捷团队的实践指南》或者想要快速浏览一下，我们建议阅读*后一章—— 第21章，然后随着它的引导来阅读。第Ⅰ部分：简介如果想快速得到如下问题的答案，如“敏捷测试和瀑布式项目测试有区别吗”、“传统测试人员和敏捷测试人员有何不同”，那么请阅读第Ⅰ部分，包含以下几章：● 第1章：敏捷测试的定义● 第2章：敏捷测试人员的十条法则这两章是Robin在其用户故事中提到的“冰山一角”，概述了敏捷和传统阶段式方法的区别，并引入了“整体团队”方式来进行质量保证和测试。在《敏捷软件测试：测试人员与敏捷团队的实践指南》的这部分中，我们讨论了“敏捷测试思想”和敏捷团队中测试人员成功的因素，解释了测试人员如何运用敏捷价值和准则来贡献他们的专业技能。第Ⅱ部分：组织挑战如果你是传统质量保证团队的测试人员或者经理，或者在指导一个团队转变到敏捷模式，那么第Ⅱ部分将帮助解决过渡期间遇到的组织挑战。“整体团队运作”代表了团队成员文化上的大部分变化，它有助于克服测试人员在害怕失去控制权或者被迫编写代码时的恐惧。第Ⅱ部分回答了如下问题：● 如何招聘质量保证团队？● 如何对待管理层的期望？● 如何组织敏捷团队，如何定位测试人员？● 聘用敏捷测试人员的标准是什么？● 如何应对分布在全球各地的团队？第Ⅱ部分也讨论了一些折磨人的主题，像如何过渡过程和模型，如审计或者符合萨班斯法案，这些要求在传统环境中很常见。度量标准和如何利用它一直富有争议，但是存在一些有效的方式使团队受益。缺陷跟踪很容易成为团队的争论焦点，热点问题包括“我们使用缺陷跟踪系统吗？”或者“何时记录缺陷？”来自传统测试团队的人员通常会询问两个常见问题：“如何制定测试计划？”和“测试项目中没有任何文档，是真的吗？”。第Ⅱ部分将解开这些谜团。
本部分包含以下各章：● 第3章：文化挑战● 第4章：团队构成● 第5章：迁移传统过程第Ⅲ部分：敏捷测试象限你想知道敏捷团队中实施的测试类型吗？你想知道谁来做哪种测试吗？如何判断所需的全部测试都已完成？如何判断哪些实践、技术和工具*适合你的情况？如果有上述疑虑，请阅读第Ⅲ部分。我们采用Brian Marick的敏捷测试象限来描述测试的目的。象限可帮助定义测试的不同领域，从单元测试到可靠性测试和其他非功能性测试，以及介于两者之间的一切测试。我们将讨论如何交付高质量的产品，介绍有助于沟通客户和理解其需求的工具。此部分展示了测试如何在各个层次上驱动开发，同时提供了工具帮助你有效地定义、设计和执行支持团队和评判团队的测试。本部分包含以下各章：● 第6章：测试的目的● 第7章：支持团队的面向技术测试● 第8章：支持团队的面向业务测试● 第9章：面向业务测试工具包● 第10章：评价产品的面向业务测试● 第11章：利用面向技术的测试评价产品● 第12章：测试象限总结第Ⅳ部分：自动化测试自动化是敏捷测试团队成功的关键，而且对很多人来说是个可怕的话题(我们知道，因为之前我们对这些生活题材曾感到过恐惧)。如何把测试自动化塞进短迭代中，而且保证项目顺利完成？第Ⅳ部分详细讲述了自动化的时机和理由、克服自动化障碍的方法，以及如何确定和实施适合自身团队的测试自动化策略。因为测试自动化工具的发展非常迅速，所以我们的目的不是介绍如何使用某个具体的工具，而是帮助你选择和使用适合自己的工具。敏捷测试自动化经验将帮助你面对各种挑战，如测试遗留代码。本部分包含以下两章：● 第13章：自动化的原因和障碍● 第14章：敏捷测试自动化策略第Ⅴ部分：测试人员的一个迭代如果只是想知道在敏捷测试周期中测试人员是如何工作的，或者想把《敏捷软件测试：测试人员与敏捷团队的实践指南》的内容综合在一起，那么请阅读第Ⅴ部分。我们以测试人员的身份讲述了一次迭代的经历。首先，我们参与计划发布和迭代使某次迭代有个良好的开端，然后进入迭代，与客户和开发团队协作，测试、编写代码。迭代的*后是发布新功能，并想办法改进过程。本部分包含以下6章： ● 第15章：测试人员在发布或主题计划阶段的工作● 第16章：迭代前的准备● 第17章：迭代开始● 第18章：编码和测试● 第19章：迭代结束时的收尾工作● 第20章：成功的交付第Ⅵ部分：总结在第21章，我们列举了敏捷团队取得测试成功的7个关键要素。如果你不知道如何开始敏捷测试或者如何改进当前的工作，这些成功要素将对你有很重要的指导意义。其他内容《敏捷软件测试：测试人员与敏捷团队的实践指南》还包含了词汇表和参考书目(书籍、文章、网站和博客)，希望对你有所帮助。现在就开始实践—— 从今天开始！敏捷开发的目的其实就是出色地工作。每一个团队都面临自己的挑战。我们努力把自己想到的可能会帮助敏捷测试人员、团队、经理和客户的信息都分享出来。请根据自身情况选择合适的技术。不断地实验、评估结果，然后重新翻书看看哪些能助你进行改进。我们的目标是帮助测试人员和敏捷团队交付*秀、*有价值的产品，并享受这个过程。我们曾询问Canoo WebTest的创始人和项目经理Dierk König，敏捷测试的*成功要素是什么？他说：“现在就开始实践—— 从今天开始！”。你可以现在就启程来改进团队的测试工作。现在就开始吧！
