敏捷測試與傳統測試的區別

在敏捷測試中也有測試活動乃至專職的測試人員，但其活動內容和目標是有顯著差別的。

通常在傳統開發團隊中，產品經理（或銷售）爲範圍或稱之爲需求負責，項目經理和開發組爲進度負責，測試組爲質量負責，部門經理爲成本負責，結果就是當四者發生矛盾時，會有四個部門各自站在本身的立場上，從而致使溝通不順暢或或博弈成分超過合做。

在敏捷開發中需求與進度的衝突由計劃會和自組織團隊機制解決，成本由BDC和故事點開發率的提高來解決（解決的很差），而進度與質量間的矛盾，則由新型的測試理念來解決。

 

在傳統測試中，測試團隊被認爲是找BUG的人，好比若是BUG衆多，則測試人員和開發人員會一塊兒加班，後者修改BUG，前者驗證是否修改好。而若是BUG很難復現，則付出努力最多的不是開發人員，而是測試人員。

在敏捷測試中，測試人員則是幫助加快進度的人，也就是提升生產率的人。一個測試人員怎麼能提升開發生產率呢？下面幾個因素保證其能夠發生。

1. 若缺陷發現越及時越容易修改。

好比在1天內就能發現，則1天內發生的改動不多，很容易找到問題。這就須要一個自動測試工具來以接近實時地發現缺陷。

好比若是在天天能進行一次持續集成，則集成測試不能經過的緣由會很單一很容易定位。設想一個數字電視系統，從受權/編碼/加密/複用/調製/發送/接收/分流/解密/顯示……環節不少信息很不透明，若在最後一刻才作集成，基本上沒法判斷問題出在哪裏。

2. 若發現缺陷的人就是製造缺陷的人，則越容易修改。

好比若是開發人員有自動測試工具能快速看看本身寫的程序有沒有問題，而不是交給測試人員發現，則更容易修改。想象一下編譯器就知道了，若是編譯活動都要委派給別人（最然如今很難想象，在軟件開發的極早期其實就是這樣的），效率會很低。

3. 一個開發人員花費在查找和修改Bug上的時間越少，則開發效率越高。

另一個推論是：在0缺陷的產品上增長一個功能，比缺陷纏身的產品上要容易得多。

所以1和2兩條的推論就是開發效率提升。

 

敏捷測試的人作什麼？

1. 不斷推動自動化測試的效率和效果。

2. 不斷推動持續集成的效率和效果。

3. 不斷提升開發人員開發功能而非處理缺陷的時間（即便缺陷是開發人員本身製造本身修改）。

固然有一個前提，就是每一個軟件對待需求/進度/質量/成本的目標和策略是不一樣的，敏捷測試人員不能有本位主義，不能片面追求測試活動自己的效果，而是應該幫助開發團隊達成其目標和策略。