本節主要介紹SOA如何逐漸融入敏捷的生命週期。在這裏，我們將研究一下應用生命週期管理（ALM）。
正如著名市場研究機構Forrester的Cary Schwaber所說的那樣，最新的ALM平臺將會改善開發過程，嚮應用工具提供普通服務。這一代的ALM軟件在將需求、測試案例、bug跟蹤和問題解決方案整合到一個應用套件中做了更多的工作。下圖就簡單說明了共享測試過程並把它作爲協作資產。
將業務需求轉換到軟件中這一過程能夠通過ALM工具自動完成。包括跟蹤編程過程、儲存源代碼、執行測試案例（目的是確保功能），並記錄產品的缺陷和改進。自動化測試歷來只是被插入到ALM的“測試執行”階段。這可以提供有關代碼覆蓋或替換成功或失敗編譯的統計數據。但是，功能更加強大的測試可以使ALM工具管理的生命週期的每一階段增值。
例如，開發人員可以根據ALM庫中存儲的源代碼檢查測試，因爲簡單化的“基本路徑”測試能夠展示已經交付組建的既定功能。接着，質量保證團隊會知曉有這些新資產，並運行和重複這些試驗證明一個更大的可能進行的活動集。但是另外一個團隊在集成和部署的過程中，可以使用開發和質量保證的所有的測試，將多個測試捆綁在一起，以確保用最小的成本得到整體迴歸和功能覆蓋。最後，隨着業務團隊和支持團隊的介入，他們可以運行、修改和檢查對於平臺的測試，以發現問題或確定ALM生命週期的下一階段。按照這種方式實現共享，測試就變成了SOA協作資產，並增加了每個迭代週期的靈活性和速度，同時更好地確保了端到端業務流程的成功。
這種做法可以被任何測試工具所採用，無論你使用的是JUnit還是自動化程度更高的、無編碼的測試工具。使用無編碼測試環境的優勢在於能夠自動化執行測試，無需編碼技能，它能夠讓非開發人員參與到上述週期中來。
在上面這個例子中，每次組件級的迭代被引入時，每個人都應該參與測試的制定和執行，這些測試被集成到一個更廣泛的工作流程和業務流程中。一個敏捷機構允許多個團隊的開發人員和非開發人員在開發結束前的很長時間就相互協作，共同致力於測試應用組件。這可以確保在每個迭代週期進行連續測試，以及更加可靠的方案修正和發佈過程。
例如，一家保險公司可能會有將郵政編碼與某種類型的汽車保險匹配的需求。開發人員創建一個組件，並利用一個能夠顯示一些郵編和保險類型匹配的簡單的測試案例對它進行檢查。質量保證團隊可以利用一個包含完整的郵編/保險類型匹配的數據集重複這一測試，並且隨後進行的系統開發都要進行這種測試。如果開發人員稍後更新了組件而所需的測試沒有通過，那麼這一情況就會報告給ALM系統，同時還配有問題根源分析。最後根據ALM系統的問題解決規則，有關團隊互相溝通之後進行問題矯正。