什么是敏捷測試?

我感覺無論我們的測試如何做，都有一種感覺，測試永遠沒有做好。覆蓋不夠，粒度不夠，文檔不全，流程不明等等。。。。。。我在想，既然這些很能做好，那么我們為什么不去承認做不好這些是正常的呢？只是個度的問題。

所以我想以后測試的方向應該向著簡單化的方向發展。那意思是說，測試更要依賴能力全面的人來擔當，而不是靠嚴格的流程去約束。 這同敏捷開發是一個道理----簡化過程，注重效率和個人能力，更加強調短周期的工作成效。

這樣做的好處是簡化了測試流程，加快測試進度，避免很多寫文檔和數據統計等浪費時間的工作。缺點是增大了不可預知的風險。  試想，原先的測試流程是：盡量解讀需求--寫用例--評審用例--用例覆蓋分析--執行用例--缺陷跟蹤--測試報告---數據統計--測試總結。并且幾乎每個階段都幫隨著一些文檔的生成和修改。那么我們看我所設想的測試過程（前提是開發按要求提供）：啟用需求管理工具和配置管理工具，每個項目中，測試人員主動到需求管理工具去解讀需求，然后到配置管理工具中去拿測試代碼和測試程序，然后就可以按自己的想法去測試（測試思路要做簡單記錄），然后借助一個即時溝通的工具進行缺陷跟蹤和與開發的交流，然后簡單匯報測試結果。

  我想后一種測試至少能把測試周期縮短2/3。但它更需要測試人員的能力。而對于企業來說，后一種方法顯然更能節約成本，縮短開發周期，產品更早的上線。既然有利益，那么這就是房展的方向。

   所以，我覺得我們要放棄cmmi那一套用文檔和會議來控制過程，選擇用我們的思路來控制過程。不過與之帶來的個人因素增加的不可預知的風險也會增多，所以說需要能做到基本不出錯誤的人才和能敏銳感覺風險的管理者。

   哈哈，一個設想，一個很有可能實現的設想。以后要加強自身能力的提高了，免得被淘汰。

原文轉自：http://www.anti-gravitydesign.com