很早就聽說過敏捷軟件開發的概念，覺得是個新生事物，挺好玩，現在IT的炒作已經太多了，後來發現敏捷的思想越來越深入人心，大大小小的公司開始使用敏捷的模式進行軟件開發。終於，敏捷來到了我的身邊。
在傳統的軟件開發模式中，系統測試屬於軟件開發過程的較後階段，基本是在所有開發代碼全部完成，開發人員拿出所有精力修改bug時纔會正式進行系統測試，包括安裝啦、穩定性啦、負載啦等等。
這次項目開始大約半年了，是一個小版本的升級，採用了scrum模式，我切實的感覺到敏捷系統測試不太對勁。在scrum中，根據開發的實際情況，設定一個時間間隔（比如每兩個周）爲一個sprint週期，每個週期都有需求跟蹤和實現，然後在進入下一個sprint階段。
目前，我發現了幾個敏捷系統測試的主要問題：
- 不斷增加的新功能導致測試結果失效。
既然是敏捷，當然是時刻適應需求的變化，於是功能不斷的改變。系統測試的結果在一次次的代碼變化之後失效，比如測試應用的穩定性，跑了兩天，內存和其他參數都沒問題，然後開發人員在下一個sprint對代碼做了很多修改，你說要不要重測？？通常這種迴歸測試都是在系統測試的最後階段，拿到最後的build的之後再測，現在呢，不得不測，如果說系統測試的工作量少也就算了，但事實上，系統測試的壓力特別大，搞的大家身心疲憊。 - 發現問題，開發人員無法適當處理。
如果在測試中發現了問題，按理說開發人員應該儘快解決，但在敏捷開發模式下，開發人員每一個sprint都有相應的需求要實現，精力有限，於是他們對於細微的bug根本置之不理，一般都會拖到最後才解決，這就導致了一個問題， 這些bug在若干次build之後會不會重現，可能在報完bug之後3個月，開發人員纔開始考慮這個問題，此時這個bug報告還有效嗎？？是不是需要重新測試？？於是我們測試人員之前的測試工作根本沒意義了。另一方面，對於嚴重的bug，開發人員也無法集中全部精力來處理，三心兩意，你說bug能解的順利嗎？後果就是開發人員和測試人員都滿心抱怨。
在我看來，這種緊跟敏捷的系統測試不是完全沒有意義，有些嚴重bug可以提早發現，開發人員可以儘早解決，但是體現了帕累託現象：我們用80%的努力得到了軟件質量20%的提高，的確，從公司老闆的角度看，這樣值得，反正軟件質量提高了，但對於開發和測試人員來說確實非常痛苦。我記得敏捷的思想來自於計算機界的各位大牛，他們在設計軟件開發模式時，沒有考慮過系統測試的特殊性嗎？還是他們從沒把系統測試包含在敏捷思想裏面，只是某些人狂熱的把敏捷錯誤的用到了系統測試當中？