测试是敏捷开发的关键组成部分。敏捷方法的广泛应用使人们开始关注如何有效测试，同时敏捷项目改变了测试人员的角色。但是，测试人员的许多职责还是得到了不少误解，测试人员的真正职能是什么？敏捷团队真的需要具有QA背景的成员吗？“敏捷测试人员”到底意味着什么？业界经验丰富的两位敏捷测试实践者和顾问Lisa、Crispin和Janet Gregory在《敏捷软件测试：测试人员与敏捷团队的实践指南》中给出了这些问题和更多问题的答案。在该书中，crispin和Gregorv定义了敏捷测试的概念，并通过来自现实敏捷团队的示例阐述测试人员的职责。她们讲述如何利用敏捷测试象限来识别需要哪些测试，谁来做，以及哪些工具有帮助。《敏捷软件测试：测试人员与敏捷团队的实践指南》从测试人员的角度记录了敏捷软件开发迭代的一个完整周期，并解释了敏捷测试的七大关键成功要素。读者将从该书中收获测试人员如何参与敏捷开发测试人员和QA经理如何适应敏捷团队敏捷测试人员的招聘要求是什么如何从传统模式迁移到敏捷模式如何在短期迭代中完成测试任务如何利用测试指导开发如何克服困难实现测试自动化《敏捷软件测试：测试人员与敏捷团队的实践指南》是敏捷测试人员、敏捷团队及其经理和客户的必备书籍。

　　克里斯平（Lisa Crispin）是一名敏捷测试实践者和教练。她专注于向测试人员和敏捷团队讲述测试人员如何创造价值并利用面向业务测试指导开发。她的使命是把敏捷的快乐带给软件测试领域，并把测试的快乐带给敏捷开发领域。Lisa在2000年一次加入敏捷团队，作为开发人员、分析人员、测试人员和质量保证主管工作了若干年。从2003年起，她成为ePlan Ser、，ices公司ePlan Services团队的测试人员。她经常在北美和欧洲的会议上教授有关敏捷测试的课程。Lisa经常发表敏捷测试的文章，刊物包括Better Software magazine、IEEE Software和Methodsand Tools。Lisa与Tip House合著了Testing Extreme Programming（Addison-Wesley,2002）。
　　格雷戈里（Janet Gregory）是DragonFire公司（致力于敏捷质量过程咨询和培训）的创始人。她希望帮助团队构建质量系统。在过去十年间，她作为教练和测试人员，把敏捷实践介绍到各种规模的公司。她关注于让业务客户和测试人员理解其在敏捷项目中的角色。Janet的编程背景使她能更好地与敏捷团队中的开发人员合作以实施新颖的敏捷测试自动化方案。Janet经常在敏捷和测试软件会议上发表演讲，也是北美敏捷测试社区的主要贡献者。

第Ⅰ部分 简介
第1章 敏捷测试的定义
1．1 敏捷价值
1．2 “敏捷测试”意味着什么
1．3 敏捷团队中角色和活动的情境
1．4 敏捷测试有何不同
1．5 整体团队运作方式
1．6 小结

第2章 敏捷测试人员的十条法则
2．1 敏捷测试人员的定义
2．2 敏捷测试思想
2．3 应用敏捷法则和价值
2．4 创造价值
2．5 小结

第Ⅱ部分 组织挑战
第3章 文化挑战
3．1 组织文化
3．2 测试／质量保证团队成功适应敏捷的障碍
3．3 引入变化
3．4 管理层期望
3．5 改变并不容易
3．6 小结

第4章 团队构成
4．1 团队结构
4．2 人员分布
4．3 人力资源
4．4 团队建设
4．5 小结

第5章 迁移传统过程
5．1 寻找轻量级过程
5．2 度量标准
5．3 缺陷跟踪
5．4 测试计划
5．5 现有的过程和模型
5．6 小结

第Ⅲ部分 敏捷测试象限
第6章 测试的目的
6．1 敏捷测试象限
6．2 知道一个用户故事何时完成
6．3 管理技术债务
6．4 上下文环境中的测试
6．5 小结

第7章 支持团队的面向技术测试
7．1 敏捷测试基础
7．2 为什么编写并运行这些测试
7．3 面向技术的测试在何处停止
7．4 如果团队不做这些测试怎么办
7．5 工具箱
7．6 小结

第8章 支持团队的面向业务测试
8．1 通过面向业务测试驱动开发
8．2 需求困境
8．3 小增量
8．4 如何知道我们完成了
8．5 小结

第9章 面向业务测试工具包
9．1 面向业务测试的工具策略
9．2 激发示例和需求的工具
9．3 基于示例自动化测试的工具
9．4 编写测试的策略
9．5 可测试性
9．6 小结

第10章 评价产品的面向业务测试
10．1 象限三简介
10．2 实例演示
10．3 场景测试
10．4 探索测试
10．4．1 基于会话的测试
10．4．2 自动化和探索测试
10．4．3 探索测试人员
10．5 可用性测试
10．5．1 用户需求和角色测试
10．5．2 导航
10．5．3 研究竞争对手
10．6 图形用户界面背后
10．6．1 API测试
10．6．2 Web服务
10．7 测试文档和文件
10．7．1 用户文档
10．7．2 报告
10．8 探索测试辅助工具
10．8．1 测试设置
10．8．2 生成测试数据
10．8．3 监控工具
10．8．4 模拟器
10．8．5 仿真器
10．9 小结

第11章 利用面向技术的测试评价产品
11．1 象限四简介
11．2 谁应该做
11．3 何时做
11．4 ilit测试
11．4．1 安全性
11．4．2 可维护性
11．4．3 交互性
11．4．4 兼容性
1114．5 可靠性
11．4．6 可安装性
11．4．7 ility小结
11．5 性能、负载、压力以及可伸缩性测试
11．5．1 可伸缩性
11．5．2 性能与负载测试
11．5．3 性能与负载测试工具
11．5．4 基准
11．5．5 测试环境
11．5．6 内存管理
11．6 小结

第12章 测试象限总结
12．1 回顾测试象限
12．2 系统测试实例
12．2．1 介绍该应用软件
12．2．2 团队和工作流程
12．3 测试驱动开发
12．3．1 单元测试
12．3．2 验收测试
12．4 自动化测试
12．4．1 自动化的功能测试结构
12．4．2 Web服务
12．4．3 嵌入式测试
12．5 评判产品的面向业务测试
12．5．1 探索性测试
12．5．2 测试数据源
12．5．3 端对端测试
12．5．4 用户验收测试．
12．5．5 可靠性测试
12．6 文档
12．6．1 用文档记录测试代码
12．6．2 汇报测试结果
12．7 熟练运用测试象限
12．8 小结

第Ⅳ部分 自动化
第13章 自动化的原因和障碍
13．1 为什么要自动化
13．1．1 手动测试需要太长的时间
13．1．2 手动过程容易出错
13．1．3 自动化让人们有时问做更有价值的工作
13．1．4 自动化回归测试提供了安全网
13．1．5 自动化测试较早并频繁地给出反馈
13．1．6 驱动编码的测试和实例可以做更多事情
13．1．7 测试是强大的文档
13．1．8 投资回报率和回报
13．2 自动化的障碍——妨碍自动化的因素
13．2．1 Bret的列表
13．2．2 我们的列表
13．2．3 程序员的态度——“为什么要自动化
13．2．4 “痛苦的积累”(学习曲线)
13．2．5 初始投入
13．2．6 总是改变的代码
13．2．7 遗留代码
13．2．8 恐惧
13．2．9 旧的习惯
13．3 可以克服这些障碍吗
13．4 小结

第14章 敏捷测试自动化策略
14．1 测试自动化的敏捷方法
14．1．1 自动化测试的分类
14．1．2 测试自动化金字塔
14．2 哪些测试可以自动化
14．2．1 持续集成、构建与部署
14．2．2 单元与组件测试
14．2．3 API或WebServices测试
14．2．4 GUI底层的测试
14．2．5 测试GUI
14．2．6 负载测试
14．2．7 比较
14．2．8 重复的任务
14．2．9 创建数据
14．3 什么测试不应该自动化
14．3．1 可用性测试
14．3．2 探索性测试
14．3．3 永远不会失败的测试
14．3．4 一次性测试
14．4 哪些测试不易于自动化
14．5 从哪里开始自动化策略
14．5．1 不愿自动化的原因
14．5．2 多层方法
14．5．3 思考测试设计与维护
14．6 选择正确的工具
14．7 将敏捷法则应用到测试自动化上
14．7．1 保持简单
14．7．2 迭代式反馈
14．7．3 整体团队运作方案
14．7．4 花时间做正确的事情
14．7．5 边做边学
14．7．6 将敏捷编码实践应用到测试上
14．8 为测试提供数据
14．8．1 数据生成工具
14．8．2 避免访问数据库
14．8．3 如果数据库访问不可避或是必须要使用数据库
14．8．4 明确所需
14．9 评估自动化工具
14．9．1 确定自动化工具的需求
14．9．2 一次一个工具
14．9．3 选择工具
14．9．4 适用于敏捷的工具
14．10 实现自动化
14．11 管理自动化测试
14．11．1 组织测试
14．11．2 组织测试结果
14．12 开始行动
14．13 小结
……
第Ⅴ部分 测试人员经历的一个迭代
第15章 测试人员在发布或主题
第16章迭代前的准备
第17章 迭代开始
第18章 编码和测试
第19章 迭代结束时的收尾工作
第20章 成功的交付
第Ⅵ部分 总结
第21章 关键成功要素
术语表
参考文献

　　“质量正在培育中”，程序员总是这样告诉我。作为收购计划的一部分，老板要求我对开发团队和其产品做彻底调查。我们已经确信该公司最近推出的产品在市场上表现良好，但是我必须确保收购投资带来的麻烦不会大于回报。因此，我花时间与开发团队在一起，寻找可能在产品快速发布时出现的问题。我会提问：“代码没有问题吗？是否有些模块是由单独一位开发人员实现的？是否可能找到成百上千个缺陷？”当询问团队的测试方式时，“质量正在培育中”就是我得到的答案。
　　因为这种独特的俗语可能存在各种解释，所以请允许我进一步说明。我发现这种说法其实是公司管理层概括了质量先驱W.Edwards：Deming的著名十四要点之一：把质量构建进产品中而不是在生产出来之后再进行测试。
　　把质量构建进产品中的思想是敏捷团队工作的中心任务。敏捷团队在短迭代中工作以确保掌握应用程序的质量状态。敏捷团队是高度跨职能的，程序员、测试人员和其他人在整个迭代中协作，通过各种技术（如验收测试驱动开发等）确保把质量构建进产品中，特别强调自动化测试和整体团队（whole-team）思维。优秀的敏捷团队通过持续地构建产品来培育质量，及时地集成新进展。敏捷团队利用各种技术（如重构和简单化）来避免技术债务累积。
　　很难学习如何做这些事情，特别是对于测试人员来说，该角色在以前的书籍中没有得到足够的重视。