任务:对任务达成共识
此任务着重在可用的测试资源和迭代目标之间寻求适当平衡。
用途
此任务的目的是:
  • 协调每个迭代中对测试资源的最有效使用
  • 针对迭代商定一组适当的、可实现的目标和可交付件
关系
步骤
了解迭代目标
目的 初步了解迭代计划的范围和目标。 

检验迭代计划,并确定计划的范围和目标。

通过与项目骨干(例如项目经理、软件设计人员和客户负责人)进行非正式讨论来补充此检验是非常有用的;这些会议通常将比计划中的文档记录更能明确地突出问题。参加迭代开始会议也会提供有用的信息。

调查评估工作范围的选项
目的 了解项目干系人对评估工作范围的期望。 

任务是在给定时间段内指导测试工作的控制主体。测试资源通常有限,所以难题是在给定的测试资源限制与软件开发工作的质量验证需要之间寻求平衡。

在战略层面上初步了解软件开发团队的期望。 您应主要关注项目经理、软件设计人员和主管系统分析人员的期望。

向项目干系人展示选项
目的 获得项目干系人对测试工作目标和范围的意见(输入信息)和反馈。 

不考虑项目团队中其他人而孤立地考虑目标和范围实在不是有用的做法。RUP 提倡团队对产品质量的主人翁精神,当决定什么测试重要时,您应将其他项目团队成员中的相关项目干系人考虑在内。您应将担任以下角色的团队成员视为重要的项目干系人:项目经理、设计人员、系统分析人员、集成人员。

在有些情况下,展示选项的形式适合比较正式,将项目干系人召集为一个复审委员会并要求提前进行大量的准备。在另一些情况下,“自带食品”午餐会或与每个项目干系人进行个别面谈可能比较适合。每种方法都有其优点和缺点:请选择在当前项目环境下最适合需要的形式。

阐述任务声明
目的 明确当前迭代的测试重点的本质。 

任务声明有助于为团队提供重点,尤其是在团队面临许多可能的选择的情况下。没有“评估任务”的测试团队通常认为他们仅是“进行测试”:这在有时间或资源限制的情况下必须就测试重点做出艰难选择时,几乎没什么指导作用。任务声明提取了当前工作目标的精要并提供一个“口头禅”,以使团队保持对正确事宜的关注。

阐述的任务声明可以由测试团队使用。不要使其过于复杂或纳入过多冲突的观点:最好的任务声明是就简单、短小和亲切,并且在需要在可能的选项之间做出决定的多数情况下,该任务会使团队应做出的决定变得明显。

下面是对您对于给定迭代可能要采用的任务声明的一些观点:

  • 找出尽可能多的错误
  • 迅速找出重要问题
  • 评估察觉到的质量风险
  • 对察觉到的项目风险提出建议
  • 对察觉到的质量风险提出建议
  • 验证标准
  • 验证规范(需求、设计或产品声明)
  • 满足项目干系人
  • 履行流程要求

彻底审查这个列表,您会想到许多任务是互相排斥的。例如,如果我的任务是“迅速找出重要问题”,我可能无法“验证规范”:为了成功完成某一任务,通常要取消其他的可能任务,并需要不同的支持测试方法。

尝试完成过多评估任务的测试团队通常会遇到麻烦,在其工作中冲突不断。 还请注意,我们建议在每个迭代中选择或重新考虑您的评估任务:根据当前工作的环境,任务随着时间而改变是很自然的。

确定测试可交付件
目的 获得测试工作将带来的价值。 

某些工作产品是对一个或多个项目干系人都很重要的可交付件:其他工作产品是测试工作的必要组成部分,尽管对测试团队很重要,但对同样的这些项目干系人却关系不大。

要为测试工作列出最少的一组有用的可交付件,请用点心思。不要列出所有工作产品;仅列出对项目干系人提供直接切实好处的工作产品以及您想要用来衡量测试工作成功情况的工作产品。您可能需要根据项目干系人的需要调整初始列表,但您将需要在使可交付件保持有用和可管理时扮演前瞻性的角色。

获取项目干系人许可
目的 与所有项目干系人协商,以便就迭代的最适合任务达成一致。 

您应通过与先前步骤向项目干系人展示选项类似的方式,获得同一些项目干系人的认同:“评估任务”及其相关的支持性方面适用于迭代。

同样,对展示任务和获取所需批准的适当形式花点心思。 选择在当前项目环境中最适合需要的形式。

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

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

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

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



属性
多次出现
事件驱动
正在进行
可选
已计划
可重复