敏捷
“敏捷”是新的過程家族的名稱
《敏捷宣言》：我們通過身體力行和幫助他人來揭示更好的軟件開發方式。經由這項工作，我們形成了如下價值觀：
個體與交互重於過程和工具
可用的軟件重於完備的文檔
客戶協作重於合同談判
響應變化重於遵循計劃
再每對對比中，後者並非全無價值，但我們更加看重前者
我們再敏捷宣言中可以看出，敏捷其實是有關軟件開發的社會工程。敏捷的主要貢獻在於他更多地思考如何去激發開發人員的工作熱情。這是在軟件工程幾十年的發展過程中相對被忽略的領域。
敏捷開發有很多種方式，其中scrum是比較流行的一種。
scrum
scrum裏面的角色
srcum由產品經理、項目經理和研發團隊組成。
- 其中產品經理負責整理用戶故事，定義其商業價值、對其進行排序、制定發佈計劃、對產品負責。
- 項目經理負責召開各種會議，協調項目、爲研發團隊服務
- 研發團隊則由不同技能的成員組成，通過緊密協同，完成每一次迭代的目標，交付產品。
迭代開發
與瀑布不同，scrum將產品的開發分解爲若干個小迭代，其週期從1週期到4週期不等，但是不會超過4周。參與的團隊成員一般是5到9人。每期迭代要完成的用戶故事是固定的。每次迭代會產生一定的交付。
scrum的基本流程如上圖所示
- 產品負責人負責整理用戶故事，形成左側的product backlog
- 發佈計劃會議：產品經理負責講解用戶故事，對其進行估算和排序，發佈計劃會議的產出就是制定出這一期迭代要完成的故事列表，spring backlog。
- 迭代計劃會議：項目團隊對每一故事進行任務分解，分解的標準是完成該story的所有任務，每個任務都有明確的負責人，並完成工時的初估計。
- 每日例會：每天scrum master召集站立會議，團隊成員回答昨天做了什麼今天計劃做什麼，有什麼問題。
- 演示例會：迭代結束之後，召開演示會議，相關成員都受邀參加，團隊負責向搭建展示本次迭代取得的成果。期間大家的反饋記錄下來，由產品經理整理，形成新的故事。
- 回顧會議：項目團隊對本期迭代進行總結，發現不足，制定改進計劃，下一次迭代繼續改進，已達到持續改進的效果。
敏捷中的測試
挑戰1：輕文檔
挑戰2：快速迭代
1、測試工作的核心內容是沒有改變的，就是不斷地找bug，只是要調整好自己的心態，一切以敏捷的原則爲主。
測試人員不能依賴文檔，測試用例作用減弱，更多的採用思維導圖，探索性測試（強調自由度，設計和執行同時執行，根據測試結果不斷調整測試計劃）、自動化測試。
3、敏捷講求合作，在敏捷項目組中，測試人員更應該主動點，多向開發人員瞭解需求，通論設計，一起研究bug出現的原因。
軟件測試的V模型
V模型最早是由Paul Rook在20世紀80年代後期提出的，目的是改進軟件開發的效率和效果。是瀑布模型的變種。
- 明確的標註了測試過程中存在的不同類型的測試，並且清楚的描述了這些測試階段和開發過程期間各階段的對應關係
- V模型指出，單元和集成測試應檢測程序的執行是否滿足軟件設計的要求；系統測試應檢測系統功能，性能的質量特性是否達到系統要求的指標；驗收測試確定軟件的實現是否滿足用戶需要或者合同的要求。
- 侷限性：僅僅把測試作爲在編碼之後的一個階段，不再需求階段就進入測試。
軟件測試W模型
- W模型增加了軟件各開發階段中應同步進行的驗證和確認活動，W模型由兩個V字性模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的並行關係。
- W模型特點：測試對象不僅是程序、需求、設計等同樣要進行測試，測試與開發是同步進行的。
- W模型的優點：有利於儘早地全面發現問題。例如：需求分析完成後，測試人員就應該參與到對需求的驗證和確認活動中，以儘早地找出缺陷所在。同時，對需要地測試也有利於及時瞭解項目難度和測試風險，急躁制定對應措施，顯著減少總體測試時間，加快項目進度。
- 侷限性：需求、設計、編碼等活動被視爲串行的：測試和開發活動也白癡這一種線性的前後關係，上一屆u但瓦努七年結束，纔可以正式開始下一個階段工作。無法支持敏捷開發模式。對於當前軟件開發複雜多變的情況，W模型並不能解除測試管理面臨着的困惑。