任务:评估并提倡质量
此任务侧重于支持确定质量差距、评估它们的影响和风险,并找到有效解决方案的整个工作。
规程:测试
用途

此任务的目的是:

  • 确定并提倡针对严重危害软件质量的缺陷的解决方案
  • 监视将软件质量提高到所需水平的变更的适当完成进度并对其提供支持
  • 提倡及时解决阻止或妨碍测试工作的缺陷
关系
步骤
检查最新的测试评估摘要
目的: 了解测试团队已确定的产品质量问题的当前摘要评估。 

首先检查测试团队准备的测试评估摘要。将评估信息与迭代的测试计划进行比较,以在所计划工作的环境下了解该摘要。如果有任何不清楚之处和关心的问题,则向准备该摘要的测试团队成员提出并予以解决。

对于此步骤和随后涉及收集信息和评估软件质量的步骤,尝试获取一个含有客观度量和主观度量的平衡视图。请记住,客观数字只能反映一部分事实,还需要根据当前的项目“状况”来配合并说明。相反,不要仅依靠有关软件质量的传闻和主观臆测:要查找可靠的客观依据。建议您与团队负责人(或可能的话,与个别团队成员)进行讨论,收集主观评估数据并判断您对客观数据可有多大置信度,从而对客观数据作出一定补充。

检查其他环境的所选测试结果
目的: 更深入地了解支持产品质量的当前摘要评估的测试结果。 

基于测试评估摘要,针对其他环境检查所选的测试结果。充分研究这些结果,以确信您了解在测试评估摘要中确定的重要问题。

同时您自己也复审这些数据,并在测试结果数据中查找可能遗漏的重要趋势依据。一般来说,更重要的是确定数据中的相对趋势表示什么而不是看绝对数字。注意有关诸如一个区域中的故障与其他区域中的故障相关联之类的暗示。

检查主要变更请求
目的: 获得背景信息,以能够有效地讨论最重要的未解决问题及其可能的解决方案。 

建议您将此做法限制在最紧迫的问题和相关联的变更请求。您将需要投入更多精力去处理较少数量的问题,它们通常可能对产品质量有极大的影响。如果您的主要问题比较多,则建议您基于它们的相对优先级对它们花费适当的精力:不要因为处理最不重要的问题而浪费资源。但请注意,大量未解决的低优先级变更请求可能跟一些高优先级变更一样,显著地反映出产品质量的问题。请尝试将较低优先级的变更请求基于其代表的质量风险而分组为质量的各个逻辑方面。这将帮助您更清楚地阐明并提倡它们对质量的组合影响。

识别一般变更请求数据中的重要趋势依据。一般来说,更重要的是确定数据中的相对趋势表示什么而不是看绝对数字。寻找有利的迹象,例如稳定、连续的缺陷解决率或解决率随着时间不断提高,随后又下降。请注意发现率的起伏较大的峰值和谷值,它们表示测试团队可能遇到降低生产力的流程问题、环境问题、政治问题或其他问题。

注意:您也可能想要利用机会改进相关联的变更请求的明确性,消除模糊不清和感性的语言与推理。如果您自行作出这些变更,请与原来创建这些工作产品的人讨论您的改进,这样他们就可以理解这些改进为什么重要。

确定质量差距并评估相关联的影响和风险
目的: 就主要问题所代表的产品质量风险以及导致软件开发项目成功的相关风险,阐述您的理解。 

确定每个质量差距并评估产生该差距的每个问题的相关影响和风险。 考虑缓解和紧急策略,表明您对它们的初始观点并与其他团队成员讨论。

我们认为“完美”质量是一种值得质疑的、有点虚构的概念。评估质量和确定质量差距时,要注意使用现实的、可实现的“质量标准”。请参阅技术:产品质量

确定处理质量差距的基本措施
目的: 生成在现实情况下所需的最少操作的列表,用于协商令人满意的解决主要问题的方法。 

对于每个主要质量差距,考虑可能的缓解与紧急策略。阐明您对这些策略的初始观点并且非正式地与其他团队成员讨论,以更多地了解并验证您的想法。在有解决方案的情况下,最好可以从中进行选择:它们帮助您作出权衡并针对给定环境采取最好的解决方案。

提出一组有用的候选解决方案和建议,它们将帮助项目团队适当地处理每个质量差距。对您来说这样做很重要,由此,测试工作被视为对解决问题很有帮助:而不只报告问题。这是提倡测试团队价值并赢得其他团队成员尊重与合作的重要方面。

确定主要问题并进行处理
目的: 非正式地获取对解决主要问题的支持,并了解哪些建议更可能被接受。 

支持注定要失败的努力一点都不可笑。这通常是确定项目团队更可能识别、接受并致力实现的问题解决方案的一种更有效方法。与主要决策者保持紧密的关系,并考虑首先通过单独讨论来非正式地展现这些主要问题。通常这是一种赢得支持并找到可实现的解决方案的好方法。

有时,您除了支持一个开发团队不欢迎的解决方案外别无选择。 像这种情况,更重要的是了解您可以从谁那里获得支持并找到使该解决方案受欢迎的方式,这些方式尽可能清晰地体现该解决方案的价值,或清晰地说明不解决该问题时会发生的更糟糕情况。

协商工作优先级
目的: 提倡在可接受的时限内可以采取的适当解决方案,该解决方案不会对所需的质量产生负面影响。 

这是提倡质量的难题:能够协商一个既满足开发团队又不明显降低产品质量的适当解决方案。记住,在多数情况下,测试团队主要是关于质量问题的顾问,所以您必须小心不要要求采取给定的解决方式。

但是,重要的是测试团队作为质量提倡者干得不错,包括有时传播项目团队不喜欢听到的消息。在这种情况下,好的测试团队使人们在开发工作能尽可能多地了解问题、对问题的可能的解决方案,并尽可能理解针对每个选择作出的权衡。您应在某种程度上充当产品最终客户的代理人,并帮助协商对他们最有利的解决方案。

监视工作进度
目的: 保持支持、关注并了解解决问题的进度。 

有时缺陷和其他变更请求会迷失在大量不断发生的基本产品开发和特性扩展之中。造成这种现象的部分原因是,对开发人员来说,处理“新东西”比修订旧代码和有问题的代码更有吸引力,还有部分原因是添加新东西比修订破东西更能明显地增加业务价值。作为质量的提倡者,测试团队需要帮助项目开发者注意重要缺陷修订直到项目完成。

成功的软件团队在通过解决缺陷来递增地改进质量和递增地扩展特性之间找到了很好的平衡点。测试团队可以协助项目团队找出鼓励和支持递增质量改进的方式,而不是扮演不太有帮助的、较为敌对的“质量警察”角色。

确认主要问题的适当解决方法
目的: 确认主要问题的解决方法有效地解决问题,而没有重大的、负面的副作用。 

无论开发团队决定使用什么解决方案来解决质量问题,该解决方法最终应改进质量。请确保花时间评估给定的解决方法所带来的质量改进,以及它不仅解决原来的问题,而且不以其他方式对质量造成负面影响。

对于本身带有某种程度风险的解决方法,在花费过多时间和精力自始至终遵循该解决方法之前,对较早的候选发行版开展某种测试可能是有用的。

评估和验证您的结果
目的: 验证任务是否已恰当地完成并且生成的工作产品是否可接受。 

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

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

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



更多信息