本节主要介绍SOA如何逐渐融入敏捷的生命周期。在这里，我们将研究一下应用生命周期管理（ALM）。
　　正如著名市场研究机构Forrester的Cary Schwaber所说的那样，最新的ALM平台将会改善开发过程，向应用工具提供普通服务。这一代的ALM 软件在将需求、测试案例、bug跟踪和问题解决方案整合到一个应用套件中做了更多的工作。下图就简单说明了共享测试过程并把它作为协作资产。
　　
　　将业务需求转换到软件中这一过程能够通过ALM工具自动完成。包括跟踪编程过程、储存源代码、执行测试案例（目的是确保功能），并记录产品的缺陷和改进。自动化测试历来只是被插入到ALM的“测试执行”阶段。这可以提供有关代码覆盖或替换成功或失败编译的统计数据。但是，功能更加强大的测试可以使ALM工具管理的生命周期的每一阶段增值。
　　例如，开发人员可以根据ALM库中 存储的源代码检查测试，因为简单化的“基本路径”测试能够展示已经交付组建的既定功能。接着，质量保证团队会知晓有这些新资产，并运行和重复这些试验证明一个更大的可能进行的活动集。但是另外一个团队在集成和部署的过程中，可以使用开发和质量保证的所有的测试，将多个测试捆绑在一起，以确保用最小的成本得到整体回归和功能覆盖。最后，随着业务团队和支持团队的介入，他们可以运行、修改和检查对于平台的测试，以发现问题或确定ALM生命周期的下一阶段。按照这种方式实现共享，测试就变成了SOA协作资产，并增加了每个迭代周期的灵活性和速度，同时更好地确保了端到端业务流程的成功。
　　这种做法可以被任何测试工具所采用，无论你使用的是JUnit还是自动化程度更高的、无编码的测试工具。使用无编码测试环境的优势在于能够自动化执行测试，无需编码技能，它能够让非开发人员参与到上述周期中来。
　
　　在上面这个例子中，每次组件级的迭代被引入时，每个人都应该参与测试的制定和执行，这些测试被集成到一个更广泛的工作流程和业务流程中。一个敏捷机构允许多个团队的开发人员和非开发人员在开发结束前的很长时间就相互协作，共同致力于测试应用组件。这可以确保在每个迭代周期进行连续测试，以及更加可靠的方案修正和发布过程。
　　例如，一家保险公司可能会有将邮政编码与某种类型的汽车保险匹配的需求。开发人员创建一个组件，并利用一个能够显示一些邮编和保险类型匹配的简单的测试案例对它进行检查。质量保证团队可以利用一个包含完整的邮编/保险类型匹配的数据集重复这一测试，并且随后进行的系统开发都要进行这种测试。如果开发人员稍后更新了组件而所需的测试没有通过，那么这一情况就会报告给ALM系统，同时还配有问题根源分析。最后根据ALM系统的问题解决规则，有关团队互相沟通之后进行问题矫正。