何謂敏捷？
敏捷在一定程度上是一種思維方式。它鼓勵個人與團隊的融合，崇尚快速響應變化，拋棄繁雜的文檔。這些從敏捷的宣言可以看出：個體和交互比過程和工具更有價值；能工作的軟件比全面的文檔更有價值；顧客的協作比合同談判更有價值；及時響應變更比遵循計劃更有價值。（見www.agilemanifesto.org）
敏捷的開發方式與傳統軟件開發方式存在很多的不同。例如，比起傳統的開發模式，敏捷方式更注重人與人之間的溝通和交互；通過區分優先級并專注于盡早發布來對待進度壓力；要求顧客緊密合作并參與到項目中來。
越來越多的人意識到傳統軟件開發模式的不足，越來越多的人開始擁抱敏捷。
質量保證在敏捷項目中的角色定位
敏捷把我們的注意力轉移到精簡的項目組、小步快跑、迭代發布的過程模式中來。那么實施敏捷項目管理的團隊是否意味著不需要文檔、不需要測試、不需要質量保證了呢？
在回答這個問題之前，我們需要考慮質量保證在敏捷項目中的角色定位問題。
抽象的思想與能工作的軟件是不一樣的，因此軟件需求文檔不能代表充分地代表軟件。敏捷方法鼓勵通過合作和面對面的交流來獲得文檔不能替代的信息溝通。那么就意味著我們傳統軟件工程中的對于需求的質量保證工作的方式不再合適了。
在敏捷項目中，軟件測試也需要敏捷。Brian Marick分析并指出了敏捷測試與傳統測試的很多不一樣的地方。敏捷測試拋棄了舊有的關于測試人員溝通方式的觀點。就像需求和設計文檔的不充分一樣，測試計劃和測試報告也是不充分的。敏捷測試要求測試員與開發人員、用戶充分交流和溝通，面對面的溝通。那么就意味著我們傳統軟件工程中對軟件測試的質量保證工作不能從檢查文檔、評審文檔出發了。
傳統的軟件測試作為質量保證的控制手段，起到質量把關的作用，測試人員站在顧客的角度來批判產品、檢查產品質量是否達到要求，測試的服務對象是顧客。但是敏捷測試的服務對象有所改變，測試的服務對象是開發組，幫助開發人員減少由于產品的不確定性而帶來的損失。（參見http://www.testing.com/writings/purpose-of-testing.htm）也就是說，質量保證的控制手段 - 軟件測試也有所不同了。
因此質量保證工作在敏捷項目組中的角色定位可能要發生一些改變，我們也許不再是抱著一堆文檔在評審，追著開發人員要文檔的QA；我們也許不再是指責產品不過關，要求返工的QA；我們也許不再是要求項目組拿出與顧客充分溝通的證據來的QA。
敏捷對質量保證的提示
目前，雖然敏捷項目管理方式逐漸興起，但是觀望的、淺嘗即止的人多于實踐的人，尤其是關于如何在敏捷項目中開展質量保證工作的實踐還比較少。因此很難準確說明敏捷項目中的質量保證工作會有哪些改變，但是我們能夠從敏捷的原則和開發方式中得到幾個有用的提示。
1、 程序員開始被測試所感染。
感謝Beck、Gamma和JUnit單元測試工具，現在，測試驅動開發被大部分的開發環境所支持。敏捷項目中的程序員更具單元測試意識。
2、 增量的開發方式
很多小的產品版本發布，而不是一個唯一的計劃好的版本發布。
3、 FIT（Framework for Integrated Test）
FIT允許用戶使用簡單的Word文檔或HTML文檔來定義他們自己的測試。FIT能產生用例子描述業務的文檔。
這些給我們的提示是：
1、測試工作不僅僅由測試人員擔任，其他項目組成員也承擔了部分的測試工作。那么對測試的質量度量模式可能就要發生改變了。
2、溝通仍然是項目組不變的主題，但是溝通的方式更多地側重在口頭、面對面方式的交流。那么對溝通的質量度量模式可能就要發生改變了。
3、迭代、快速發布、重構等軟件開發方式對如何進行配置管理的控制提出了新的要求。
總結
敏捷項目管理代表了一種軟件開發思想的回歸，軟件的本質是為用戶提供價值，為用戶解決問題。所有軟件工程的活動都是圍繞這個核心思想來進行的。極限編程、測試驅動、SCRUM等等，都只是為了突現軟件活動中的某方面的重要性而提出的，但其核心都一樣。
個體和交互、能工作的軟件、顧客合作、快速響應變化，這些原則毫無疑問會使傳統的質量保證工作方式發生改變。很多質量保證的手段和方式可能要發生劇烈的改變，但是至少有一樣東西是不變的：質量保證的目的仍然是確保交付產品的質量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
