很早就聽說過敏捷軟體開發的概念，覺得是個新生事物，挺好玩，現在it的炒作已經太多了，後來發現敏捷的思想越來越深入人心，大大小小的公司開始使用敏捷的模式進行軟體開發。終於，敏捷來到了我的身邊。
在傳統的軟體開發模式中，系統測試屬於軟體開發過程的較後階段，基本是在所有開發**全部完成，開發人員拿出所有精力修改bug時才會正式進行系統測試，包括安裝啦、穩定性啦、負載啦等等。
這次專案開始大約半年了，是乙個小版本的公升級，採用了scrum模式，我切實的感覺到敏捷系統測試不太對勁。在scrum中，根據開發的實際情況，設定乙個時間間隔（比如每兩個周）為乙個sprint週期，每個週期都有需求跟蹤和實現，然後在進入下乙個sprint階段。
目前，我發現了幾個敏捷系統測試的主要問題：
不斷增加的新功能導致測試結果失效。
既然是敏捷，當然是時刻適應需求的變化，於是功能不斷的改變。系統測試的結果在一次次的**變化之後失效，比如測試應用的穩定性，跑了兩天，記憶體和其他引數都沒問題，然後開發人員在下乙個sprint對**做了很多修改，你說要不要重測？？通常這種回歸測試都是在系統測試的最後階段，拿到最後的build的之後再測，現在呢，不得不測，如果說系統測試的工作量少也就算了，但事實上，系統測試的壓力特別大，搞的大家身心疲憊。
發現問題，開發人員無法適當處理。
如果在測試中發現了問題，按理說開發人員應該盡快解決，但在敏捷開發模式下，開發人員每乙個sprint都有相應的需求要實現，精力有限，於是他們對於細微的bug根本置之不理，一般都會拖到最後才解決，這就導致了乙個問題， 這些bug在若干次build之後會不會重現，可能在報完bug之後3個月，開發人員才開始考慮這個問題，此時這個bug報告還有效嗎？？是不是需要重新測試？？於是我們測試人員之前的測試工作根本沒意義了。另一方面，對於嚴重的bug，開發人員也無法集中全部精力來處理，三心兩意，你說bug能解的順利嗎？後果就是開發人員和測試人員都滿心抱怨。
在我看來，這種緊跟敏捷的系統測試不是完全沒有意義，有些嚴重bug可以提早發現，開發人員可以盡早解決，但是體現了帕累託現象：我們用80%的努力得到了軟體質量20%的提高，的確，從公司老闆的角度看，這樣值得，反正軟體質量提高了，但對於開發和測試人員來說確實非常痛苦。我記得敏捷的思想來自於計算機界的各位大牛，他們在設計軟體開發模式時，沒有考慮過系統測試的特殊性嗎？還是他們從沒把系統測試包含在敏捷思想裡面，只是某些人狂熱的把敏捷錯誤的用到了系統測試當中？
**ckword技術部落格
SOA，測試人員的噩夢？
對於it人員來說，soa已經不僅僅是一種技術，它代表了一種新的，更加巨集觀的設計和實施it系統的方 那麼對於整個it系統的實施過程來說，每乙個步驟都按照soa的角度來考慮，來實施就成為了soa專案實施過程中的重點和難點。介面開發的發展促成了soa的發展，soa的諸多優勢之中介面規範的標準化是比較突出...
敏捷測試的核心
q 質量內建跟敏捷測試的關係是什麼？能分開嗎？a 我認為質量內建是敏捷測試的核心。敏捷測試是相對於傳統測試而言的，在聊敏捷測試之前，我們先看傳統測試是什麼樣的。傳統測試通常有如下的特點 敏捷測試的目標也不再是發現更多的bug，而是盡快的交付高質量的軟體。那麼軟體的高質量怎麼獲得呢？著名質量管理專家指...
敏捷測試團隊的測試流程
一 接到專案後，ba明確客戶的需求，必要時可以帶上測試經理 開發經理 測試員 開發員，出乙份書面需求說明 二 測試人員初步學習 ba串講 測試人員提問題 ba給出回答 重新整理學習 測試人員反串講 評審 出乙個需求規格說明書 模組思維導圖 三 測試經理根據需求規格說明書制定測試計畫 此spirit共...