任务:评估并改进测试工作
此任务着重对测试工作进行及时更改,以提高其成效。
规程:测试
用途

此任务的目的是:

  • 对测试工作的生产力、成效和完成情况进行评估
  • 对测试工作进行(战术和战略上的)调整,以提高成效
关系
步骤
捕获工作状态
目的 针对计划,获取对测试工作的一般状态的最新及客观理解。 

有多种方式可执行此步骤,并且执行的很大部分将取决于您的项目文化。收集和整理由个别团队成员或子团队准备的进度报告(如果有)。项目时间表是可以考虑的另一个可能的来源。如果积极使用诸如 Microsoft Project 之类的项目时间安排系统并以实际进度更新,这可以提供另一种有用的信息来源。您也可以从配置与变更管理系统(如果有并积极使用)中得出客观的状态或进度度量值。

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

收集测试工作生产力和成效度量值
目的 收集和检验那些支持评估测试(由测试团队执行)的客观数据。 

调查对确定、定义、实施和执行测试花费了多少精力。要留意,不要将过多精力花费在测试工作的某一方面而损害其他方面。也要注意工作低效或者对所花费的精力程度没有体现足够优点的领域。

还要注意测试的效用。查找支持初始观察效用的数据。测试结束时,考虑诸如缺陷恢复率、缺陷严重性计数、重复缺陷统计量和检测到的测试疏忽等方面。

收集变更请求分布、趋势和帐龄度量值
目的 收集和检验那些支持评估问题和缺陷(由测试团队记录)的客观数据。 

识别变更请求数据中的重要趋势依据。一般对这个任务来说,花时间分析数据量不太重要,更重要的是确定相对数据趋势表示的含义。寻找有利的迹象,例如稳定、连续的缺陷发现率或发现率随着时间略微提高或下降。请注意发现率的起伏较大的峰值和谷值,它们表示测试团队可能遇到降低生产力的流程问题、环境问题、政治问题或其他问题。

查看缺陷闭合的趋势。查找由开发人员作为“不可复制”而作出的关闭的明显增加量;确定由于测试团队执行的故障分析不充分而导致的情形,并量化这个问题的程度。查看由开发人员作为“按设计运作”而关闭的缺陷的趋势;确定由于测试团队所执行的规范分析不充分而导致的情形,并量化这个问题的程度。小心确认这些暗示不是虚假的并应处理,而不是让工作过量的开发人员减轻其工作量。当在以后的工作版本中将缺陷的修订发布给测试团队时,也应对缺陷验证趋势进行分析:注意哪些表示缺陷等待测试团队验证的趋势正在熟化,或增长到无法控制的数目。

查找表示有问题的其他趋势。看一下测试团队记录或管理缺陷和其他变更请求的方式:有关变更请求的信息模糊而不足,对于开发人员来说采取措施就非常困难和令人沮丧。团队应注意监视针对保持平均数量较高的缺陷记录的信息的质量。 利用机会改进相关联的变更请求的明确性,消除模糊不清和感性的语言与推理。与创建这些工作产品的人员合作,可确保阐明问题的本质,并鼓励他们找到实际而精确的方式来着手讨论这些问题。

还要注意缺陷多维分发的不平衡情况。查找缺陷数较低的应用程序或规范功能区:这可能表明已在该功能区进行了不充分的测试。还要观察测试团队成员的分发:可能会有个别团队成员工作过度而生产力降低的迹象。

收集可跟踪性、覆盖率和依赖关系度量值
目的 收集和检验那些支持评估资产可跟踪性的客观数据。 

分析测试资产(测试观点、测试用例、测试脚本、测试套件和变更请求)和它们相关的上行资产与上行资产之间的可跟踪性关系的状态。查找表示测试工作注重于正确区域和一组有用动机的迹象。还要查找表示测试的某些方面被遗漏或不再重要的负面指示:如果需求或开发团队正在处理并非由当前测试工作所代表的区域,则这应引起注意。

评估度量值并形成初始评估
目的 对照计划评估度量数据并形成对测试工作成效的初始评估。 

对照所有已收集的信息并将其作为一个整体进行评估。请记住,每条收集的数据仅针对整体评估的一个方面,您必须基于对数据的平衡而且考虑过的了解来阐明您对测试工作的评估。

以适于项目干系人提出意见和给出反馈的形式记录您的初始评估。

记录调查结果
目的 记录摘要调查结果以将其包含在项目管理报告中,并对照早期评估,支持对后续状态评估进行分析。 

此任务生成摘要状态信息,这些信息对项目经理和管理团队中的其他角色很重要。这些角色将使用摘要调查结果就该项目做出全面合理的决策。

建议您记录测试工作评估的某些方面,所采用的形式允许将后续的评估和与以前的评估进行比较。这将使您能分析测试工作随着时间改进的相对趋势。

展示评估并收集反馈
目的 引入项目干系人,并获得他们的反馈,了解实际测试工作是否满足其需求。 

展示您的评估,使项目干系人提出意见并提供反馈。这样做的形式或方法将因项目而异:在有些情况下是一系列非正式对话,在另一种情况下只是在项目内部网 Web 站点上发公告,在其他情况下则是正式展示 - 请选择适合您的文化的形式。

即使可能有最好的计划和规范文档,通常原始期望与文档用意和产生的最终产品之间还是有差异的。对于测试和评估软件是这样,对软件开发本身也是这样。此步骤的价值是利用机会引发项目干系人的反馈,并确定小心计划和文档没有实现原本预期或设计的目标的情况。

计划和实施改进行动
目的 确定要改进的区域,并形成实现这些改进的初始策略。 

基于您的分析以及从各个项目干系人处收到的反馈,确定改进的机会。查找提高测试效用、生产力以及效率的方式。这可能包括:重新分配人员,包括搭配人员以更有效地工作或雇佣专业承包商;使用得力工具提高效率;查找在查找缺陷方面更有效的备用方法和技术。

在多数情况下,最好是对测试工作进行小幅度的递增改进,并避免因为大而混乱的变更导致项目脱轨的风险:在有些情况下,较大的更改是可以的并很有用。使用您的最佳判断阐明改进的适当方法,并与其他管理人员讨论您的观点以听取他们的评论意见,然后让整个团队进行大的变更。

监视和支持改进行动
目的 确保以令人满意而及时的方式完成必要的改进行动。 

要使改进有效,您将需要管理他们的成功之处。确定您将能够监视改进行动的方式(最好是在采纳行动之前),以评估他们的效用。可以积极监视您自行采纳更改时的更改进度,或指定团队中的别人这样做。

多数变更会面临它们取得最终成功所必须克服的阻力或问题。给它们时间,并准备好快速解决所出现的、阻止行动成功的任何问题。警惕那些天生不愿改变的人,并设法相应地解决他们所关注的问题。

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

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

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

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