軟件測試中敏捷：系統測試的噩夢
很早就聽說過敏捷軟件開發的概念，覺得是個新生事物，挺好玩，現在IT的炒作已經太多了，后來發現敏捷的思想越來越深入人心，大大小小的公司開始使用敏捷的模式進行軟件開發。終于，敏捷來到了我的身邊。
首先敏捷測試是敏捷的一種，原有測試定義中通過執行被測系統發現問題，通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。 敏捷測試是遵循敏捷宣言的一種測試實踐： 1、強調從客戶的角度，即使用系統的用戶的角度，來測試系統。 2、重點關注持續迭代的測試新開發的功能，而不再強調傳統測試過程中嚴格的測試階段。 3、建議盡早開始測試，一旦系統某個層面可測，比如提供了模塊功能，就要開始模塊層面的單元測試，同時隨著測試深入，持續進行回歸測試保證之前測試過內容的正確性。
在傳統的軟件開發模式中，系統測試屬于軟件開發過程的較后階段，基本是在所有開發代碼全部完成，開發人員拿出所有精力修改bug時才會正式進行系統測試，包括安裝啦、穩定性啦、負載啦等等。
這次項目開始大約半年了，是一個小版本的升級，采用了scrum模式，我切實的感覺到敏捷系統測試不太對勁。在scrum中，根據開發的實際情況，設定一個時間間隔（比如每兩個周）為一個sprint周期，每個周期都有需求跟蹤和實現，然后在進入下一個sprint階段。
目前，我發現了幾個敏捷系統測試的主要問題：
不斷增加的新功能導致測試結果失效。
既然是敏捷，當然是時刻適應需求的變化，于是功能不斷的改變。系統測試的結果在一次次的代碼變化之后失效，比如測試應用的穩定性，跑了兩天，內存和其他參數都沒問題，然后開發人員在下一個sprint對代碼做了很多修改，你說要不要重測？？通常這種回歸測試都是在系統測試的最后階段，拿到最后的build的之后再測，現在呢，不得不測，如果說系統測試的工作量少也就算了，但事實上，系統測試的壓力特別大，搞的大家身心疲憊。
發現問題，開發人員無法適當處理。
如果在測試中發現了問題，按理說開發人員應該盡快解決，但在敏捷開發模式下，開發人員每一個sprint都有相應的需求要實現，精力有限，于是他們對于細微的bug根本置之不理，一般都會拖到最后才解決，這就導致了一個問題， 這些bug在若干次build之后會不會重現，可能在報完bug之后3個月，開發人員才開始考慮這個問題，此時這個bug報告還有效嗎？？是不是需要重新測試？？于是我們測試人員之前的測試工作根本沒意義了。另一方面，對于嚴重的bug，開發人員也無法集中全部精力來處理，三心兩意，你說bug能解的順利嗎？后果就是開發人員和測試人員都滿心抱怨。
在我看來，這種緊跟敏捷的系統測試不是完全沒有意義，有些嚴重bug可以提早發現，開發人員可以盡早解決，但是體現了帕累托現象：我們用80%的努力得到了軟件質量20%的提高，的確，從公司老板的角度看，這樣值得，反正軟件質量提高了，但對于開發和測試人員來說確實非常痛苦。我記得敏捷的思想來自于計算機界的各位大牛，他們在設計軟件開發模式時，沒有考慮過系統測試的特殊性嗎？還是他們從沒把系統測試包含在敏捷思想里面，只是某些人狂熱的把敏捷錯誤的用到了系統測試當中？
文章來源于領測軟件測試網 http://www.k11sc111.com/
