挑战
以下是在敏捷系统测试活动中面临的一些最重要的挑战。
短迭代
系统测试场景的回归测试发生在第 2 到 6 的迭代周中。在第 2 到 4 周中，系统测试还需要提高并单元测试系统测试应用程序，以便它可以用于第 5 和 6 周中的新功能的测试。
对于新功能的系统测试场景的执行只发生在第 5 和 6 周。这种时间长度证明，当在后面的迭代中系统测试运行更加复杂时，在这种“现场试验”过程中，对场景的子集进行测试是种挑战。举例来说，在测试需要更复杂的拓扑，以及比三天更长的持续时间，和/或伴随中断和故障测试的复杂工作负载的情况下，在分配的时间内包含这些复杂的场景是困难的。这些较复杂的场景趋于暴露出较困难的故障，它们更难调试，并且有时是间歇的。用追踪重新创建这些类型的缺陷是耗费时间的，因为我们应用补丁并检验集成到驱动程序中的修复。在分配给少量测试人员的情况下，这是非常困难的。因此，一些较复杂的场景和缺陷需要跨迭代。
即使只有一个应用程序用于应用程序开发和场景执行，应用程序开发还是耗费迭代中的大量时间。通过为了对应用程序进行一些功能增强而扩展到两个迭代，在一个迭代进行应用程序开发而当需要时在以后的迭代中执行场景，来部分地减少浪费。
另一个挑战是迭代结果审查和演示的计时。在第 6 周，系统测试团队向整个团队提出他们的迭代结果。在一些迭代中，最后一周没有完成测试，从而提出结果，并且系统测试结果的提出需要移动到后继迭代的第 1 周。同样，有时系统测试团队负责一部分向产品管理层的演示，从而显示迭代的可交付件。这些演示需要大量的准备，而在后面的迭代中系统测试团队的参与更困难。
另一个使得第 5 和 6 周非常具有挑战的因素是系统测试需要培训开发人员进行系统测试的执行，以便那些开发人员在后面的迭代中可以辅助系统测试。然而，这需要有经验的系统测试人员来指导那些在特殊的迭代中分派到系统测试的开发人员，增加完成计划的系统测试承诺的难度。由于这涉及对于不熟悉系统测试的开发人员大约 1-2 周的学习曲线，所以如果将同样的开发人员分派到多个连续迭代的系统测试中才可以实现系统测试的好处，这不总是可能的。
第一个敏捷开发经验
对于大部分团队成员来说，该项目是敏捷开发中的首次经历，对于该项目，开发和系统测试活动的并行对团队的每个人都是陌生的。系统测试团队的五个人比预期超时工作。在项目过程中，每个人，包括系统测试团队成员，都了解如何估量每个迭代的设计、开发，和测试任务。过度承诺或错误的估计对系统测试团队，以及整个团队的其他成员产生了压力。
用例
在敏捷的周期早期需要定义并实现跨迭代的用例的标准化命名约定。为了确保系统测试团队不忘记任何用例，并且让所有团队都能够清楚地辨别每个用例，拥有一贯地使用的（从第一个迭代到最后的迭代）标准化的“用例标识符”是有帮助的。
模板用于一贯地编制跨整个团队的用例。虽然用例的概念对整个团队不是全新的，但是根据外部的客户价值陈述用例对大部分团队成员来说是陌生的。因此，由于迭代末尾的“所了解的经验的”反馈（其中包含来自整个团队的反馈，包括客户交付团队），用例描述的模板和用词不断地变化。
在项目过程中，客户文档是格式化的用例文档。由于系统测试不能得到标准的外部客户级文档，因此系统测试团队不能测试这类客户文档。如果该标准的产品文档在未来生成，那么它需要额外的测试工作。
好处
以下是与敏捷的系统测试工作相关的具体好处。
较好的系统测试应用程序
由于在许多迭代过程中一系列的连续增强，所开发的系统测试应用程序拥有较高的质量。当进行所有这些改进时，应用程序的许多其他方面也改进了，包括执行的验证、提供的日志，及异常处理。由于在许多月内进行开发，所以测试应用程序更加健壮，这与在传统的，集中的测试准备阶段中开发的相反。
提高了的全部系统测试的加速时间
在敏捷的环境中，与开发密切合作的核心系统测试团队向开发组织提供了重大的潜在好处。核心团队可以为在产品发布之前在最终系统测试时的使用而生成系统测试应用程序、场景，和自动脚本的子集。与开发并行地创建并执行这些资料将帮助让较广大的系统测试团队生产的更快。
出于技能转移的立场，系统测试核心团队在适当的时候可以向较广大的系统测试团队介绍新的技术和版本内容。核心团队可以提出类似客户的应用程序设计，并向广大的团队演示应用程序，同时提供所开发的文档、已建立的开发联系的指示，因而提高全部系统测试迭代的加速时间。
在全部系统测试开始时的提高了的产品质量
因为系统测试核心团队在产品开发周期的早期执行系统测试的子集，所以在正式进入完全的系统测试时应该提高代码质量，这必定影响较广的系统测试团队的生产力。此外，利用参与早期系统测试活动的系统测试核心团队的发布周期（在其后，产品发布之前，进行集中的完全的系统测试）可以提供与传统的开发/测试方法相比，提高了的质量。注意写到此时，最终的系统测试迭代还没有开始。在开发迭代中，由于系统测试核心团队早期的测试，与压力相关的及内存泄漏缺陷的子集在正式的系统测试开始之前就被除掉了。
结束语
本文所讨论的项目是小型的。它包含大约五十五个人，包括经理、架构师、开发人员，和测试人员。有大约十二个不同的组分团队，包括致力于开源技术的团队、它们是作为技术功能基础的团队。组分团队在不同的地理位置，然而，每个团队的小型规模使它在项目中相当容易地采用敏捷的开发原则。利用瀑布方法的项目的前期当作是项目中使用的技术的培训。这些先前的技术培训令到敏捷概念的过渡更容易。团队没有额外的技术学习曲线的困难。
迭代 1 用作过渡迭代，用于完成已经在开发中，并作为敏捷项目而开始运作的可交付件。敏捷开发过渡适当地启动，并且带有对前两个迭代的适度的开发承诺。主要的焦点在于在团队和建立的过程之间构建人与人之间的文化，例如，并行的早期系统测试应用程序开发和执行，这将会用于在新的环境中令团队成功。根据此项目的结果，鼓励花费在从瀑布开发到敏捷开发的过渡阶段上的时间。
在六个迭代中，系统测试核心团队与开发团队并行工作。这令传统的系统测试应用程序的开发和执行的子集在每个迭代中都能够运行。这种并行导致了以下方面的成功：
跨多个迭代增量地构建更健壮且实际的系统测试应用程序。
开发、功能验证测试，和系统测试之间较密切的沟通使得大家听到了许多观点，并形成系统测试的执行。
项目中使用的技术和环境中较深入的技能。
在产品周期较早期除去一些系统测试缺陷。
每个迭代都进行过程或测试的改进。
