在产品周期早期除去的缺陷

    因为在迭代过程中，系统测试执行回归、压力，和持续时间执行，所以在缺陷注入不久就被确定并除去了。由于产品代码在开发人员心里是新写的，所以系统测试可以收到来自开发的立即的修复。在敏捷的环境中，系统测试更容易检验修补，由于缺陷周转时间较快，并且由于准确的测试环境仍旧适当。因为工作在相同时间的相同用例上，开发人员和系统测试人员有相同的优先权，由此开发人员和系统测试人员之间的协作较好。这便于缺陷更快地确定、修复，及检验。

    较早的迭代测试初始且较基本的产品功能。此次，系统测试应用程序还是基本且较简单的，然而，为了找到缺陷，能够在特定压力级别和持续时间内运行。后续的迭代引入了增加的产品功能和更复杂的产品配置。系统测试应用程序的功能和复杂度也增加了。在后继的迭代中，压力的等级和测试持续时间增加了。一般，在这些后继的迭代中可以找到更复杂的缺陷，但仍旧非常接近于注入产品的时间。

    一般来说，在敏捷的开发周期中对系统测试缺陷的开发关注较多。这导致了较早地检测出缺陷，并且更快地缺陷修复周转时间。

    过程演进

    敏捷开发本身虑及了连续的增强。在迭代的末尾有一个“了解到的经验”的会话，让所有的参与者确定问题区域，并建议整体的改进和效率。

    敏捷模型的一个关键特征是开发过程应该演进。这对所有与产品交付件相关的团队来说都是正确的，包括系统测试。在每个迭代中都实现了关于如何提高生产力的洞察。每个团队被要求提供他们关于了解到什么及可以提高什么的想法。整个团队开会并讨论每一个痛处或成功点。在该对话中，确定出额外的改进，从在线存储库中获得，并集成到下一个迭代中。

    与系统测试相关的过程演进的一个具体实例发生在第一个迭代期间，在该迭代中，系统测试团队形式化一个用于测试追踪的过程。在过去，测试追踪工具用于定义系统测试场景及编档测试执行结果。在迭代 1 中，系统测试团队为那些测试场景定义模板，并且创建公共的配置文档。这些配置文档允许系统测试团队详述由一个公共的文档源安装并执行公告的系统测试规程所必要的步骤。这个独立的定义令个别的测试人员能够避免创建并维护重复的文档。所有相关的测试场景都指向公共的文档。

    系统测试团队如何增量地改进他们的过程的另一个实例出现在内存泄漏分析被引入到迭代 3 中时，而不是等到最后的，只进行系统测试的迭代。如前面提到的，该变更是可能的，由于代码的稳定性。公共的配置文档中加入了必要的工具和安装说明，这是每个计划的测试场景所参考的。同样，测试完成的详情包括每次运行后的内存泄漏分析的结果。

    系统测试团队定义约定及编写良好的过程，来帮助实现可重复的且一致的测试。在开始项目的测试工作之前，许多改进都还不为人知或未定义。一些想法基于“发现”，而其他的纯粹来源于对随后迭代的生产力提高的期望。“所了解的经验”的频率及对模型灵活性的关注令整个团队避免较早的痛处，提高效率，并试用解决方案。

    停船识别

    从迭代 3 开始，系统测试团队推动停船场景的识别。从迭代 4 开始，在迭代承诺会议过程中，系统测试团队的场景分类为停船货非停船。为了成功地完成迭代，所有的停船场景必须在没有缺陷或补丁的情况下成功运行。停船测试场景一般是那些在前面的迭代执行，并作为归回场景转到当前迭代的测试案例。这些测试场景还组合形成了一组同时执行的测试。比起较早的迭代，这些组合的测试一般在较高的负载下执行，并且还至少执行二十四小时。

    非停船的测试场景一般基于需要在后来的迭代中交付的客户需求，但基于当前迭代中正在开发的功能。这允许在功能验证完成之后不久执行最初的系统测试和问题确定。敏捷环境中的这种附加的灵活性令复杂的问题得以确定、隔离、追踪、修补，并在跨多个迭代的时间段里在系统测试环境中执行。

    系统测试团队在测试追踪工具中区别停船和非停船测试场景。在迭代的第 1 周中的承诺会议上，高级架构师指导将每个承诺划分为停船和非停船的。那些分类记录于在线承诺页上，并随后当为每个承诺创建测试执行记录时使用。对于停船场景，测试阶段有在迭代的系统测试周期末尾的完成日期，发生在第 5 和 6 周。非停船场景遍及多个迭代，但在最终迭代中，所有余下的非停船场景都成为停船场景。通过允许当未预期的问题出现时应用附加的资源，以较低优先级的测试场景为代价，测试场景之间的差别帮助管理风险。这令迭代交付按计划完成，但需要对非停船场景后备的小心管理。

    挑战

    以下是在敏捷系统测试活动中面临的一些最重要的挑战。

    短迭代

    系统测试场景的回归测试发生在第 2 到 6 的迭代周中。在第 2 到 4 周中，系统测试还需要提高并单元测试系统测试应用程序，以便它可以用于第 5 和 6 周中的新功能的测试。

    对于新功能的系统测试场景的执行只发生在第 5 和 6 周。这种时间长度证明，当在后面的迭代中系统测试运行更加复杂时，在这种“现场试验”过程中，对场景的子集进行测试是种挑战。举例来说，在测试需要更复杂的拓扑，以及比三天更长的持续时间，和/或伴随中断和故障测试的复杂工作负载的情况下，在分配的时间内包含这些复杂的场景是困难的。这些较复杂的场景趋于暴露出较困难的故障，它们更难调试，并且有时是间歇的。用追踪重新创建这些类型的缺陷是耗费时间的，因为我们应用补丁并检验集成到驱动程序中的修复。在分配给少量测试人员的情况下，这是非常困难的。因此，一些较复杂的场景和缺陷需要跨迭代。

    即使只有一个应用程序用于应用程序开发和场景执行，应用程序开发还是耗费迭代中的大量时间。通过为了对应用程序进行一些功能增强而扩展到两个迭代，在一个迭代进行应用程序开发而当需要时在以后的迭代中执行场景，来部分地减少浪费。

    另一个挑战是迭代结果审查和演示的计时。在第 6 周，系统测试团队向整个团队提出他们的迭代结果。在一些迭代中，最后一周没有完成测试，从而提出结果，并且系统测试结果的提出需要移动到后继迭代的第 1 周。同样，有时系统测试团队负责一部分向产品管理层的演示，从而显示迭代的可交付件。这些演示需要大量的准备，而在后面的迭代中系统测试团队的参与更困难。

    另一个使得第 5 和 6 周非常具有挑战的因素是系统测试需要培训开发人员进行系统测试的执行，以便那些开发人员在后面的迭代中可以辅助系统测试。然而，这需要有经验的系统测试人员来指导那些在特殊的迭代中分派到系统测试的开发人员，增加完成计划的系统测试承诺的难度。由于这涉及对于不熟悉系统测试的开发人员大约 1-2 周的学习曲线，所以如果将同样的开发人员分派到多个连续迭代的系统测试中才可以实现系统测试的好处，这不总是可能的。

    第一个敏捷开发经验

    对于大部分团队成员来说，该项目是敏捷开发中的首次经历，对于该项目，开发和系统测试活动的并行对团队的每个人都是陌生的。系统测试团队的五个人比预期超时工作。在项目过程中，每个人，包括系统测试团队成员，都了解如何估量每个迭代的设计、开发，和测试任务。过度承诺或错误的估计对系统测试团队，以及整个团队的其他成员产生了压力。

    用例

    在敏捷的周期早期需要定义并实现跨迭代的用例的标准化命名约定。为了确保系统测试团队不忘记任何用例，并且让所有团队都能够清楚地辨别每个用例，拥有一贯地使用的（从第一个迭代到最后的迭代）标准化的“用例标识符”是有帮助的。

    模板用于一贯地编制跨整个团队的用例。虽然用例的概念对整个团队不是全新的，但是根据外部的客户价值陈述用例对大部分团队成员来说是陌生的。因此，由于迭代末尾的“所了解的经验的”反馈（其中包含来自整个团队的反馈，包括客户交付团队），用例描述的模板和用词不断地变化。

    在项目过程中，客户文档是格式化的用例文档。由于系统测试不能得到标准的外部客户级文档，因此系统测试团队不能测试这类客户文档。如果该标准的产品文档在未来生成，那么它需要额外的测试工作。

    好处

    以下是与敏捷的系统测试工作相关的具体好处。

    较好的系统测试应用程序

    由于在许多迭代过程中一系列的连续增强，所开发的系统测试应用程序拥有较高的质量。当进行所有这些改进时，应用程序的许多其他方面也改进了，包括执行的验证、提供的日志，及异常处理。由于在许多月内进行开发，所以测试应用程序更加健壮，这与在传统的，集中的测试准备阶段中开发的相反。

    提高了的全部系统测试的加速时间

    在敏捷的环境中，与开发密切合作的核心系统测试团队向开发组织提供了重大的潜在好处。核心团队可以为在产品发布之前在最终系统测试时的使用而生成系统测试应用程序、场景，和自动脚本的子集。与开发并行地创建并执行这些资料将帮助让较广大的系统测试团队生产的更快。

    出于技能转移的立场，系统测试核心团队在适当的时候可以向较广大的系统测试团队介绍新的技术和版本内容。核心团队可以提出类似客户的应用程序设计，并向广大的团队演示应用程序，同时提供所开发的文档、已建立的开发联系的指示，因而提高全部系统测试迭代的加速时间。

    在全部系统测试开始时的提高了的产品质量

    因为系统测试核心团队在产品开发周期的早期执行系统测试的子集，所以在正式进入完全的系统测试时应该提高代码质量，这必定影响较广的系统测试团队的生产力。此外，利用参与早期系统测试活动的系统测试核心团队的发布周期（在其后，产品发布之前，进行集中的完全的系统测试）可以提供与传统的开发/测试方法相比，提高了的质量。注意写到此时，最终的系统测试迭代还没有开始。在开发迭代中，由于系统测试核心团队早期的测试，与压力相关的及内存泄漏缺陷的子集在正式的系统测试开始之前就被除掉了。

    结束语

    本文所讨论的项目是小型的。它包含大约五十五个人，包括经理、架构师、开发人员，和测试人员。有大约十二个不同的组分团队，包括致力于开源技术的团队、它们是作为技术功能基础的团队。组分团队在不同的地理位置，然而，每个团队的小型规模使它在项目中相当容易地采用敏捷的开发原则。利用瀑布方法的项目的前期当作是项目中使用的技术的培训。这些先前的技术培训令到敏捷概念的过渡更容易。团队没有额外的技术学习曲线的困难。

    迭代 1 用作过渡迭代，用于完成已经在开发中，并作为敏捷项目而开始运作的可交付件。敏捷开发过渡适当地启动，并且带有对前两个迭代的适度的开发承诺。主要的焦点在于在团队和建立的过程之间构建人与人之间的文化，例如，并行的早期系统测试应用程序开发和执行，这将会用于在新的环境中令团队成功。根据此项目的结果，鼓励花费在从瀑布开发到敏捷开发的过渡阶段上的时间。

    在六个迭代中，系统测试核心团队与开发团队并行工作。这令传统的系统测试应用程序的开发和执行的子集在每个迭代中都能够运行。这种并行导致了以下方面的成功：

    跨多个迭代增量地构建更健壮且实际的系统测试应用程序。
    开发、功能验证测试，和系统测试之间较密切的沟通使得大家听到了许多观点，并形成系统测试的执行。
    项目中使用的技术和环境中较深入的技能。
    在产品周期较早期除去一些系统测试缺陷。
    每个迭代都进行过程或测试的改进。