任务:确定测试激励因素
此任务描述了如何确定特定项(包括事件和工作产品)列表,这些特定项将用于激发此迭代中的测试。
规程:测试
关系
步骤
确定迭代目标项
目的 获得对迭代计划背后的特定目标的初始理解。 

检查迭代计划,并识别将控制计划的特定项,以及度量计划的执行将依靠的关键可交付件。您应检查的关键元素包括:风险列表、变更需求列表、需求集、用例列表、UML 模型等等。

参加迭代开始会议对于补充此检查是有用的。如果尚未计划,则请为测试团队组织一次会议,邀请 关键的管理和软件开发资源参加(例如项目经理、软件设计人员和开发团队领导)。

收集和检验相关信息
目的 获得对迭代计划的范围和特定可交付件更详细的理解。 

在检查了迭代计划之后,首先寻找实在的且明确定义的元素,这些元素是进行评估的不错的候选者。检验要执行的工作所包含的详细信息,包括“新工作”和变更请求等。研究将要由计划解决的风险,以清晰地了解风险的潜在影响是什么,以及要解决它所必须做的是什么(降低、转移、消除等等)。

确定候选激发因素
目的 概述作为迭代的候选者的测试激发因素。 

使用您对迭代计划已经获得的理解,识别将激发测试工作的事物的潜在源。激发可能来自任意数量源中的一个:个别工作产品、一组工作产品、一个事件或活动、或者缺少任何这些事物。源可以包括:风险列表、变更请求、需求集、用例和 UML 模型等。

对于每个源,检查潜在激发因素的详细信息。如果您找不到很多相关的 详细信息,或者您对激发源不熟悉,则与分析人员和项目成员就这些项进行讨论可能对您有用,这些讨论通常以与项目经理或领导系统分析人员的讨论开始。

在您检查信息并就信息与相关人员进行讨论时,枚举一列候选测试激发因素。

确定质量风险
目的 确定哪些质量风险与此迭代相关性最大。 

使用候选测试激发因素列表,在质量风险的可能性方面考虑每个激发因素。这将帮助您更好地理解每个候选者的相对重要性,并可以发现列表中遗漏的其他候选激发因素。

质量风险存在许多不同方面,可能单个激发因素可以在多个类别突出风险的可能性。突出针对每个候选激发因素的潜在质量风险,并指示遭遇到的风险的可能性,以及风险发生的影响。

定义激发因素列表
目的 定义特定的测试激发因素,这些因素将成为此迭代的焦点。 

通过使用候选激发因素的列表,以及激发因素的质量风险信息,确定激发因素的相对重要性。确定可在当前迭代中解决的激发因素(您可能想要为后续迭代保留剩余候选者列表)。

定义激发因素列表,适当时记录该列表。它可以作为迭代测试计划的一部分,采用数据库或电子表格的形式,或者作为包含在某个其他工作产品中的列表。简要描述激发因素的重要性以及它将帮助解决的质量风险的侧重面是有用的。

维持可跟踪性关系
目的 使得能对跟踪的项执行影响分析和评估报告。 

通过使用在测试计划中概述的可跟踪性需求,按照需要更新可跟踪性关系。

评估和验证结果
目的 验证任务已恰当地完成,生成的工作产品是可以接受的。 

既然您已完成了该工作,那么最好验证该工作是否有足够的价值,而且您并不是简单地消耗大量纸张。您应评估您的工作质量是否适当,是否完整得足以让其他团队成员觉得您的工作很有用,并随后将它们用作他们自己工作的输入源。在可能的情况下,请使用 RUP 中提供的核对表验证质量和完整性是否都“足够好”。

让执行下行任务(根据您输入的工作信息)的人员参与复审您的过渡工作。请在您还有时间针对他们的意见采取行动时让他们参与复审。 您还应针对主要输入工作产品评估您的工作,以确保您已精确并充分地展示了它们。让输入工作产品的作者以此为基础复审您的工作,这可能很有用。

请记住,RUP 是一个迭代的交付流程,并且在许多情况下工作产品是随着时间而演进的。所以,通常没必要完全形成将在近期的后续工作中只部分使用或根本不用的工作产品,并且这通常对生产力有副作用。这是因为很有可能在使用工作产品前,工作产品周围的情况会发生变化(并且在创建工作产品时作出的假设也会证明是不正确的),从而带来工时的浪费和高成本的重复工作。同时也要避免在展示内容值的危害方面花费过多周折的陷阱。 在展示作为项目可交付件有很大的重要性而且有经济价值的项目环境中,您可能希望考虑使用管理资源来执行展示任务。



更多信息