活动:
|
目的
|
角色:测试管理员 |
频率:此活动通常在每个迭代执行多次。. |
步骤 |
输入工件: | 生成的工件: |
工具向导: |
更多信息: |
工作流程明细: |
目的: | 了解测试团队已确定的产品质量问题的当前摘要评估。 |
首先检查测试团队准备的测试评估摘要。将评估信息与迭代的测试计划进行比较,以在所计划工作的环境下了解该摘要。如果有任何不清楚之处和关心的问题,则向准备该摘要的测试团队成员提出并予以解决。
对于此步骤和随后涉及收集信息和评估软件质量的步骤,尝试获取一个含有客观度量和主观度量的平衡视图。请记住,客观数字只能反映一部分事实,还需要根据当前的项目“状况”来配合并说明。相反,不要仅依靠有关软件质量的传闻和主观臆测:要查找可靠的客观依据。建议您通过与团队领导(或个别团队成员,如有可能)进行讨论来补充您的客观数据,以收集主观评估数据并判断客观数据可能有多大的置信度。
目的: | 更深入地了解支持产品质量的当前摘要评估的测试结果。 |
基于测试评估摘要,针对其它环境检查所选的测试结果。充分研究这些结果,以确信您了解在测试评估摘要中确定的重要问题。
同时您自己也复审这些数据,并在测试结果数据中查找可能遗漏的重要趋势依据。一般来说,更重要的是确定数据中的相对趋势表示什么而不是看绝对数字。注意有关诸如一个区域中的故障与其它区域中的故障相关联之类的暗示。
目的: | 获得背景信息,以能够有效地讨论最重要的未解决问题及其可能的解决方案。 |
建议您将此做法限制在最紧迫的问题和相关联的变更请求。您将需要投入更多精力去处理较少数量的问题,它们通常可能对产品质量有极大的影响。如果您的主要问题比较多,则建议您基于它们的相对优先级对它们花费适当的精力:不要因为处理最不重要的问题而浪费资源。但请注意,大量未解决的低优先级变更请求可能跟一些高优先级变更一样,显著地反映出产品质量的问题。请尝试将较低优先级的变更请求基于其代表的质量风险而分组为质量的各个逻辑方面。这将帮助您更清楚地阐明并提倡它们对质量的组合影响。
识别一般变更请求数据中的重要趋势依据。一般来说,更重要的是确定数据中的相对趋势表示什么而不是看绝对数字。寻找有利的迹象,例如稳定、连续的缺陷解决率或解决率随着时间不断提高,随后又下降。请注意发现率的起伏较大的峰值和谷值,它们表示测试团队可能遇到降低生产力的流程问题、环境问题、政治问题或其它问题。
注意:您也可能想要利用机会改进相关联的变更请求的明确性,消除模糊不清和感性的语言与推理。如果您自行作出这些变更,请与原来创建这些工件的人讨论您的改进,这样他们就可以理解这些改进为什么重要。
目的: | 就主要问题所代表的产品质量风险以及导致软件开发项目成功的相关风险,阐述您的理解。 |
确定每个质量差距并评估产生该差距的每个问题的相关影响和风险。考虑缓解和紧急策略,表明您对它们的初始观点并与其他团队成员讨论。
我们认为“完美”质量是一种值得质疑的、有点虚构的概念。评估质量和确定质量差距时,要注意使用现实的、可实现的“质量标准”。请参阅概念:产品质量
目的: | 生成在现实情况下所需的最少操作的列表,用于协商令人满意的解决主要问题的方法。 |
对于每个主要质量差距,考虑可能的缓解与紧急策略。阐明您对这些策略的初始观点并且非正式地与其他团队成员讨论,以更多地了解并验证您的想法。在有解决方案的情况下,最好可以从中进行选择:它们帮助您作出权衡并针对给定环境采取最好的解决方案。
提出一组有用的候选解决方案和建议,它们将帮助项目团队适当地处理每个质量差距。对您来说这样做很重要,由此,测试工作被视为对解决问题很有帮助:而不只报告问题。这是提倡测试团队价值并赢得其他团队成员尊重与合作的重要方面。
目的: | 非正式地获取对解决主要问题的支持,并了解哪些建议更可能被接受。 |
支持注定要失败的努力一点都不可笑。这通常是确定项目团队更可能识别、接受并致力实现的问题解决方案的一种更有效方法。与主要决策者保持紧密的关系,并考虑首先通过单独讨论来非正式地展现这些主要问题。通常这是一种赢得支持并找到可实现的解决方案的好方法。
有时,您除了支持一个开发团队不欢迎的解决方案外别无选择。像这种情况,更重要的是了解您可以从谁那里获得支持并找到使该解决方案受欢迎的方式,这些方式尽可能清晰地体现该解决方案的价值,或清晰地说明不解决该问题时会发生的更糟糕情况。
目的: | 提倡在可接受的时限内可以采取的适当解决方案,该解决方案不会对所需的质量产生负面影响。 |
这是提倡质量的难题:能够协商一个既满足开发团队又不明显降低产品质量的适当解决方案。记住,在多数情况下,测试团队主要是关于质量问题的顾问,所以您必须小心不要要求采取给定的解决方式。
但是,重要的是测试团队作为质量提倡者干得不错,包括有时传播项目团队不喜欢听到的消息。在这种情况下,好的测试团队使开发工作尽可能多地了解问题、其可能的解决方案,并尽可能理解对每个选择作出的权衡。您应在某种程度上充当产品最终客户的代理人,并帮助协商对他们最有利的解决方案。
目的: | 保持支持、关注并了解解决问题的进度。 |
有时缺陷和其它变更请求会迷失在大量不断发生的基本产品开发和特性扩展之中。这部分是因为对开发人员来说,处理“新东西”比修订旧代码和有问题的代码更有吸引力,部分是因为添加新东西比修订破东西更能明显地增加企业价值。作为质量的提倡者,测试团队需要帮助在完成时看出项目的重要缺陷修订。
成功的软件团队在通过解决缺陷来递增地改进质量和递增地扩展特性之间找到了很好的平衡点。测试团队可以协助项目团队找出鼓励和支持递增质量改进的方式,而不是扮演不太有帮助的、更为敌对的“质量警察”角色。
目的: | 确认主要问题的解决方法有效地解决问题,而没有重大的、负面的副作用。 |
无论开发团队决定使用什么解决方案来解决质量问题,该解决方法最终应改进质量。请确保花时间评估给定的解决方法所带来的质量改进,以及它不仅解决原来的问题,而且不以其它方式对质量造成负面影响。
对于本身带有某种程度风险的解决方法,在花费过多时间和精力自始至终遵循该解决方法之前,对较早的候选发行版开展某种测试可能是有用的。
目的: | 验证活动已恰当地完成,结果工件是可以接受的。 |
既然您已完成了该工作,那么最好验证该工作有足够的价值,而且您并不是简单地消耗大量纸张。您应评估您的工作质量是否适当,是否完整得足以让其他团队成员觉得您的工作很有用,并随后将它们用作他们自己工作的输入源。在可能的情况下,请使用 RUP 中提供的清单验证质量和完整性都“足够好”。
让执行下行活动(根据您输入的工作信息)的人员参与复审您的过渡工作。请在您还有时间针对他们的意见采取行动时让他们参与复审。您还应针对主要输入工件评估您的工作,以确保您已精确并充分地展示了它们。在这种情况下让输入工件的作者复审您的工作可能很有用。
请记住,RUP 是一个迭代的过程,在很多情况下工件会随着时间而演进。所以,通常没必要完全形成将在临近的随后工作中只部分使用或根本不用的工件,并且这通常对生产力有副作用。这是因为很有可能在使用工件前,工件周围的情况会发生变化(并且在创建工件时作出的假设也会证明是不正确的),从而带来工作量的浪费和高成本的返工。还要避免将太多的周期浪费在展示内容值的亏损上。在展示作为项目可交付工件具有重要性和经济价值的项目环境中,您可能希望考虑使用管理资源来执行展示任务。
Rational Unified Process
|