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

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

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

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

在傳統測試中，測試團隊被認為是找bug的人，比如如果bug眾多，則測試人員和開發人員會一起加班，後者修改bug，前者驗證是否修改好。而如果bug很難復現，則付出努力最多的不是開發人員，而是測試人員。

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

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

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

比如如果在每天能進行一次持續整合，則整合測試不能通過的原因會很單一很容易定位。設想乙個數碼電視系統，從授權/編碼/加密/復用/調製/傳送/接收/分流/解密/顯示……環節很多資訊很不透明，若在最後一刻才做整合，基本上無法判斷問題出在**。

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

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

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

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

因此1和2兩條的推論就是開發效率提高。

敏捷測試的人做什麼？

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

2. 不斷推進持續整合的效率和效果。

3. 不斷提高開發人員開發功能而非處理缺陷的時間（即使缺陷是開發人員自己製造自己修改）。

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