更好的团队合作之缺陷篇:有效沟通的10个建议(3)

发表于:2011-10-27来源:未知作者:领测软件测试网采编点击数: 标签:缺陷管理
在缺陷分析和评估的过程中,可能会使用不同的缺陷相关的 度量 ,例如:各种缺陷状态的累计数量、新提交的缺陷和已处理的缺陷之间的对比关系、新提

  在缺陷分析和评估的过程中,可能会使用不同的缺陷相关的度量,例如:各种缺陷状态的累计数量、新提交的缺陷和已处理的缺陷之间的对比关系、新提交的缺陷和已关闭的缺陷之间的对比关系、缺陷不同优先级的分布情况、缺陷不同严重程度的分布情况、发现的缺陷在不同模块之间的分布等。根据不同的组织策略和项目特点,可以选择不同度量指标对测试进度、测试质量、产品质量等进行分析。

  8)不要期望修复所有发现的缺陷

  测试的主要目的是发现软件中的缺陷,同时为项目成员和管理人员提供关于软件系统的足够的信息,帮助他们做出正确的决定。从测试人员的角度,总是希望发现的缺陷能够全部解决,而项目管理人员对缺陷的修复考虑得可能更多。例如:

  ◆ 项目层面:全局考虑缺陷的严重程度和优先级。在有限的时间内,首先解决那些优先级或严重程度高的缺陷。

  ◆ 风险因素:修改每个缺陷都可能在代码中引入新的缺陷。假如修改一个小的缺陷可能产生更严重的软件错误,或者存在产生更严重软件错误的风险,就需要考虑是不是在当前版本中修改这个缺陷。

  ◆ 成本因素:有的缺陷修复的成本可能会高于修复后得到的收益,例如:缺陷所在的软件模块,在用户使用中的优先级并不是很高,而项目的进度很紧。这个时候,项目团队可能会选择先发布软件版本,而在下一个版本中修复该缺陷。

  不管是对测试活动,还是对测试中发现的缺陷的修复,都需要在时间、成本、质量和风险之间平衡。测试人员也应该站在更高的层面对待测试活动,以及每个测试活动的工作产品。

  9)不要让延迟修复的缺陷消失

  在测试过程中发现的一些缺陷并不一定在当前版本中修复。对于不在当前版本修复的缺陷,测试人员和项目管理人员都应该对它们进行跟踪和管理,避免此类缺陷的消失。假如延迟修复的缺陷计划在下个版本中进行修复,那么下一个版本启动的同时,就启动这些缺陷的修复任务,因为这个时候项目的进度压力、工作量压力和时间压力是最小的。

  10)变更和变更的沟通

  测试过程中经常发生的一个问题是:当测试人员提交缺陷报告后,开发人员直接拒绝了缺陷报告,并通知测试人员系统的设计已经被修改。为了避免类似情况的发生,测试人员或者测试经理需要采取一些措施,例如:

  ◆ 在提交缺陷报告之前,假如时间和条件允许,要求开发人员在测试环境中确认缺陷的存在,可以避免这样的问题。

  ◆ 假如组织或者项目有成熟的版本管理系统,那么要求开发人员按照版本管理的要求进行相关文档的修改,从而可以使测试人员了解软件设计的变更,避免测试时间和测试资源的浪费,提高测试的效率。

  ◆ 假如组织或者项目没有版本管理系统,那么测试经理和开发经理之间需要有良好的沟通。测试经理可以要求开发经理在作为测试依据的开发文档发生变更时,告知测试经理,从而避免这种问题的发生。

原文转自:http://www.ltesting.net