從一個實例詳解敏捷測試的最佳實踐

第一部分：敏捷軟件開發簡介

敏捷軟件開發（Agile Software Development）初起于九十年代中期。最早是為了與傳統的瀑布軟件開發模式（waterfall model）相比較，所以當時的方法叫做輕量級方法（Lightweight methods）。二十世紀初，17 位該方法的倡導者建立了敏捷聯盟（Agile Alliance），并將該軟件開發方法命名為敏捷軟件開發過程。

敏捷聯盟在成立之初總結了四條基本的價值原則：

1. 人員交流重于過程與工具（Individuals and interactions over processes and tools）
2. 軟件產品重于長篇大論（Working software over comprehensive documentation）
3. 客戶協作重于合同談判（Customer collaboration over contract negotiation）
4. 隨機應變重于循規蹈矩（Responding to change over following a plan）

基于這四點原則，敏捷軟件開發有著自己獨特的流程（參見圖 1）。

圖 1. 敏捷軟件開發流程

整個過程中夾雜了很多在敏捷開發前己經出現的軟件開發方法，包括極限編程（Extreme Programming,1996）、Scrum（1986）、特征驅動開發（Feature Driven Development），測試驅動開發（Test Driven Development）等。這些方法在敏捷軟件開發流程的各個階段都有充分的體現和應用。

例如，Scrum 主要著重于項目管理，團隊中的項目經理（Scrum master）需要在每個客戶需求到來的時候制定 Sprint 的周期，定義每個 Sprint 的目標、分派任務、進行監督、最后總結得失并開始計劃新的 Sprint。

相反，特征驅動開發和測試驅動開發主要被應用于 Sprint 周期中。如果項目進行于開發新功能時期，這個階段主要推行特征驅動開發。所有測試和開發人員都將自己的工作重心放在新的功能上面，從開發和測試兩個方面來完成各自的任務。如果項目進行于測試新功能時期，這個階段需要將工作的重點挪到測試上來。所有的測試和開發人員都密切關注著目前版本的缺陷狀況。測試人員需要在每天的站立會議（Daily Standup Meeting）上報告前一個工作日發現的新缺陷情況，項目經理根據項目進度和缺陷嚴重性來決定是否修復這些問題。需要及時修復的缺陷是目前 Sprint 中的一個新任務，將由項目經理添加到 Sprint Backlog 上并通知開發人員去修復漏洞。

原文轉自：https://www.ibm.com/developerworks/cn/rational/r-cn-agiletestexplain/