场景:XYZ 公司拥有八个在建的软件项目。他们在 ClearQuest 测试管理中设置了八个资产注册。他们使用著名岛屿的名字作为项目的代号,于是资产注册也因此而的名(请参见图1)。其中两个项目(Aruba 和 Bermuda)拥有地理上分散的团队,所以 ClearQuest 管理员设置了 IBM® Rational® ClearQuest® MultiSite 使得远程团队能够对 ClearQuest 进行访问。
测试之下的所有软件产品都得到了三款最主要的平台的支持:Microsoft® Windows®、UNIX® 和 Linux®。由于配置是在所有资产注册中被共享的,所以项目管理者要共同决定能够适合所有项目的配置的集合。他们为这些全球配置使用一个前缀,用以指出全部的优先级。然而,其中两个项目要求唯一的配置。出于这个原因,除了将配置的全球集合统一用 P#
作为前缀之外,还将创建其他的一些配置。为了轻易识别出那些配置将被应用到哪一个项目中,配置的名称就要以项目代号的起头两个字母作为前缀。图2显示了属性和值。
图3显示了这个配置。
项目管理者的下一项任务就是协调迭代名称的使用。对命名约定进行标准化将使得横跨多个项目的报告成为可能,特别是被包括在同一个发布中的项目更是如此。在被管理的八个项目之中,有四个是在同一个软件发布中的,另外四个则是独立的产品。所有项目都遵循相似的过程;因此,管理者设计一个命名约定,它包括主要的发布版本和次要的发布版本,以及开发和测试阶段。由于迭代是针对一个特定的资产注册的,所以它们需要在每一个资产注册中创建必要的迭代。
前面四个项目(Aruba、Bermuda、Fiji 和 Hawaii)是发布4、版本2的全部组成部分。Aruba 和 Bermuda 仍处于建造阶段,正在进行功能性确认测试。Fiji 和 Hawaii 正处于系统确认测试阶段。因此它们将为这些项目创建以下迭代:
当这些团队在发布周期中前行的时候,他们能够通过遵守相同的命名约定添加迭代。通过这样做,他们将能够运行或者基于测试阶段或者基于横跨特定版本的更高层级的报告。请注意,在不同的资产注册中拥有相同名称的迭代没有问题。在这个场景的后面,ClearQuest 测试管理将自动将资产注册名称作为前缀添加到迭代名称中,所以 XYZ 团队总是能够区分出彼此。
其余的项目均是独立的产品,他们分散在不同的发布进度之上。然而,处于一贯性的考虑,管理者也应当遵循相同的命名约定。用于这些项目的迭代设置如下: