敏捷軟件測試：測試人員與敏捷團隊的實踐指南（簡體書）

《敏捷軟件測試:測試人員與敏捷團隊的實踐指南》內容簡介：測試是敏捷開發的關鍵組成部分。敏捷方法的廣泛應用使人們開始關注如何有效測試，同時敏捷項目改變了測試人員的角色。但是，測試人員的許多職責還是得到了不少誤解，測試人員的真正職能是什麼？敏捷團隊真的需要具有QA背景的成員嗎？“敏捷測試人員”到底意味著什麼？
業界經驗最豐富的兩位敏捷測試實踐者和顧問Lisa、Crispin和Janet Gregory在《敏捷軟件測試:測試人員與敏捷團隊的實踐指南》中給出了這些問題和更多問題的答案。在《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》中，crispin和Gregorv定義了敏捷測試的概念，并通過來自現實敏捷團隊的示例闡述測試人員的職責。她們講述如何利用敏捷測試象限來識別需要哪些測試，誰來做，以及哪些工具有幫助。《敏捷軟件測試:測試人員與敏捷團隊的實踐指南》從測試人員的角度記錄了敏捷軟件開發迭代的一個完整周期，并解釋了敏捷測試的七大關鍵成功要素。
讀者將從《敏捷軟件測試:測試人員與敏捷團隊的實踐指南》中收獲
測試人員如何參與敏捷開發
測試人員和QA經理如何適應敏捷團隊
敏捷測試人員的招聘要求是什麼
如何從傳統模式遷移到敏捷模式
如何在短期迭代中完成測試任務
如何利用測試指導開發
如何克服困難實現測試自動化《敏捷軟件測試:測試人員與敏捷團隊的實踐指南》是敏捷測試人員、敏捷團隊及其經理和客戶的必備書籍。

作者：（美國）克里斯平（Lisa Crispin） （美國）格雷戈里（Janet Gregory） 譯者：孫偉峰 崔康

克里斯平（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 敏捷價值
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 可靠性
l1.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章 關鍵成功要素
術語表
參考文獻