任务:获取可测性承诺
此任务着重于定义和提升可测性需要及收益,并划分其优先级。
用途

此任务的目的是:

  • 提升可测软件(支持测试工作的需要)的创建
  • 提升并支持相应的自动化技术和工具的使用
关系
步骤
检验可测性需要
目的 很好地理解需要由软件交付流程或软件体系结构和设计来处理的测试实施和评估需要。 

研究测试自动化体系结构和测试接口规范,以很好地理解测试实施和评估需要。特别地,理解这些需要将施加给软件交付流程或软件体系结构和设计的约束。

评估影响和划分优先级
目的 识别对于测试工作最重要的可测性需要,并在解决较不重要的需要之前首先倡导对这些重要需要的解决。 

研究可测性需要,并在对未满足需要的测试工作的影响方面执行基本影响分析。还请考虑开发团队所需要的潜在工作的一些基本分析,为该需要调查并提供解决方案。对于每项需要,识别可能的备选解决方案,这些备选方案对开发团队的效果较小。

通过使用此信息,制定一份排列了优先级的列表,该列表将对测试工作有重大影响,但却没有得到满足,且尚没有备选解决方案的需要排在最前面。这样做的目的有两点:避免将宝贵的开发资源浪费在不是很必要的可测性需要上,而将该机会留给真正重要的需要。

定义可测性收益
目的 使得能在基本成本效益方面将可测性需要的价值出售给项目干系人。 

通过要求开发团队遵守测试工作的特定规定来开发软件,您将向开发工作进一步添加需求和约束;这本质上等同于向开发团队添加了更多的工作和附加的风险与复杂性。某些开发团队会将可测性的设计视为在它们职责范围之外。在其他情况中,可测性需要必须与客户需要以及通常被授予更高优先级的需求在开发资源上展开竞争。因此,您需要使项目经理、软件设计人员和开发团队中的其他项目干系人了解并认同可测性需要的收益。

为每项您想要获得委托的可测性需要的益处制定一份分析。研究支持您的可测性需要的价值的论文、文章和调查报告,并在适用的场合利用 ROI 统计量。在以下方面考虑益处:提供给开发团队的价值;您能向他们提供什么有用的评估信息,这些信息在不满足此需要的情况下是无法提供的? 它将如何使得您能更早或更有效率地在每个构建周期内向开发团队提供及时的、精确的、深入的或有用的反馈? 此需要是否向开发团队提供了有用的特性,该特性可用在他们自己的测试工作中,或用在将来的软件故障诊断中? 在与客户需要竞争的情况下,请考虑您能显示以下结论的方法,即较早地对可测性需要提供 解决方案将向客户需求提供附加的在后续构建周期中获得支持的机会。

确定并鼓励可测性优胜者
目的 与重要的项目干系人组成联盟,这些项目干系人将拥护构建可测软件,并在这点上支持测试团队需要。 

假定您对开发团队可能施加附加工作或风险,您应标识那些有影响力的项目干系人(这些项目干系人有能力核准或命令对可测性的支持)并与他们配合。在积极地提升您希望受支持的可测性需要之前,尽可能早地完成这项工作。

最重要的三个项目干系人是:软件设计人员、项目经理和客户代表。请花费时间与软件设计人员商谈,并提升创建支持可测性的软件体系结构的价值。花时间与项目经理交流,提升可测性在测试团队工作效率方面的益处,并快速地返回评估信息。鼓励客户为要交付的优质产品贡献自己的力量。

提升可测性需要和收益
目的 就测试工作的重要可测性需要通知相关项目干系人,并赢得他们对可测性的支持。 

以正确的方式提升可测性是很重要的。项目经理、开发团队和客户项目干系人 的每种组合具有不同的动机和文化,当您提升可测性需要时,要对这种情况保持敏感,这很重要。作为一般的试探,如果团队相对松散和不正式,请勿组织正式的可测性“竞赛”;请勿在非常正式的项目中使用非正式的方法。

在一些情况中,协作的“头脑风暴”会议是一种有用的表现形式,在该会议中,将通过对开发团队提问来展示需要,鼓励开发团队 确定创造性的解决方案来满足可测性需要。这鼓励了他们拥有解决方案,并培养对工作的参与感。

计时对于此步骤也是重要的。作为一般规则,您应尽可能早地识别和提升最重要的可测性问题,这通常发生在精化阶段,也可能发生在先启阶段。当在项目的这些早期阶段提出可测性问题时,团队通常较小且更容易接受更改。而且也更容易将这些需要包含在改良的设计中,因为通常需要的返工量最小。

识别可测性需要,并以积极而不那么“正式”的方式表现这些需要的一个好的方案是:让测试团队在下列工作中提供服务:评估“概念验证”活动,以及评估供开发工作使用的第三方组件的选择。特别地,在数据库组件选择、UI 控制或组件选择、中间件组件等方面涉及到测试团队,说明可测性问题可用作组件选择条件的一个方面。例如,在许多情况下,开发团队对要利用哪个 UI 窗口小部件库不是很在意,如果某个库的可测性好于另一个库,开发团队将乐于选择这个可测性更好的窗口组件库。

如果您在标识可测性优胜者或与他们配合方面遇到麻烦,您可能需要 考虑一种方法,该方法引进更多的变更,使它们的潜在风险更小,工作块更小;或者您可能必须逐步将最重要的可测性需要上升到关键项目问题,如果这些问题得不到解决,将阻碍测试工作的成功。对于后一种情况,我们建议您在决定此操作过程之前仔细考虑所有选项。

获得支持并维护可测性的承诺
目的 获得一份协议,该协议规定开发团队将继续支持和维护可测性特性。 

确保以相同的方式考虑可测性需要与任何其他施加于开发工作的需求或约束,这很重要。您需要确保,今天生效的可测性特性不会在明天就被抛弃。

在一些情况下,尝试获得此承诺可能导致开发团队拒绝开发或支持可测性需要。尽管这可能是令人沮丧的,但尽可能早地了解此情况并处理此现实问题总比回避它要好。如果是耗费了大量时间和工作量来开发测试实施,然后开发团队又放弃对它的支持承诺,那么情况要糟得多。

倡导可测性问题的解决方法
目的 监视和拥护可测性问题的解决。 

尽管开发团队可能同意为测试工作的可测性需要提供必要的支持,但您仍应对此工作的设计、实施和完成表现出积极的兴趣,这很重要。不要仅仅因为开发团队已同意满足可测性需要或已开始进行解决方案的研究就放弃对此的关系;您需要确保以及时的方式开发适当的解决方案。

使您自己和其他测试团队成员随时准备好回答开发团队的问题,且一旦构建了原型,就提供评估。提供有建设性的反馈,并对开发团队就帮助满足您的需要而进行的工作表现出热心。对于更为复杂的可测性需要,让您的关键人员参加或协助设计研讨会,但应提防 您的团队在开发人员的设计流程解决方案领域反客为主而控制该领域。

如果出现问题,且您觉得问题没有得到足够的注意,或者解决问题的速度不够,请向软件设计人员和项目经理表达您对这些问题的关注。如果合适,请让项目经理将问题记录在项目问题列表上。

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

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

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

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



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