【出自网络】更好的团队合作之缺陷篇：有效沟通的10个建议

lsekfe

有效地沟通可以在缺陷管理中避免项目利益相关者之间的相互指责，支持收集和解释目标信息。缺陷报告的准确性、合理的分类和客观的表述有助于改善缺陷报告提交人员和缺陷修复人员之间的关系。测试人员应考虑到缺陷的重要性，并提供可用的客观信息。

缺陷评审会议应致力于进行适当的缺陷优先级和严重程度的判定。缺陷的跟踪工具可以促进成员之间的沟通，缺陷评审会议并不能代替缺陷跟踪工具。有效的沟通和良好的工具支持有助于实现高效的缺陷管理。下面介绍缺陷沟通过程的常见问题和注意事项。

1）缺陷的认定

测试人员提交缺陷报告后，经常会出现测试人员认为这是软件系统的一个缺陷，而开发人员认为这是正常的系统功能。到底是缺陷还是正常功能？这是测试人员和开发人员在缺陷问题上经常出现的分歧。

测试人员对测试对象进行测试的时候要使用正确的测试依据（例如：需求规格说明）。软件开发过程中，主要涉及的项目技术人员包括系统人员、开发人员和测试人员。他们之间的角色和职责定义有助于解决缺陷认定的问题。图1是三者之间的简单关系示意图，系统人员是软件开发和软件测试的基础和核心。系统人员将产品的用户需求转化为详细的产品需求规格说明。在需求规格说明基线化后，软件人员以此作为基础进行系统概要设计和详细设计，而测试人员根据规格说明进行测试用例的设计。同时，软件开发人员和软件测试人员都需要和系统人员紧密合作，将各个阶段的开发活动和测试活动得到的信息反馈给系统人员，完善和优化系统需求规格说明。按照这样角色和职责的定义，测试人员和开发人员在碰到缺陷认定的时候，首先可以由系统人员做出相应的裁决。

图1项目开发的三种角色

当然，这种关于是不是缺陷的解决方案是基于相对成熟的软件开发过程的。由于有了明确的角色和职责定义，软件开发人员和测试人员的工作都是基于系统人员提供的产品需求规格说明。因此，在测试过程中发现的问题可以基于共同的理解和基础，从而减少对具体问题的分歧，提高沟通的效率，同时可以提高开发和测试活动的效率。

对于测试中发现的功能问题，开发人员和测试人员之间比较容易达成共识。但是，对于软件非功能相关的问题，由于相关的规格说明中经常没有进行详细定义，因此容易出现缺陷认定方面的争议。此时，测试人员需要具有良好的沟通能力，并对测试理论和领域知识有比较深入的了解。下面是在缺陷认定出现不一致的时候，缺陷相关人员可以借鉴的一些建议：

◆ 首先，测试人员应该让开发团队理解提交缺陷的目的并不是对开发人员的成果进行挑刺，相反，测试人员和开发人员的目标是一致的，都是为了提高软件产品的质量，满足客户的需求。

◆ 其次，需要和开发人员进行有效地沟通，让开发人员理解测试的目的不仅仅只是针对软件的功能而开展，还包括了可靠性、易用性、效率、维护性、可移植性等其他质量属性。因此，发现非功能特性的缺陷时，开发人员不应该因为系统需求规格说明中没有详细定义，而否认存在的问题。

◆ 第三，测试人员应该站在用户的角度对软件的使用质量属性进行有效地测试，包括软件的有效性、生产率、安全性以及满意度等。

◆ 第四，假如测试人员和开发人员在缺陷认定沟通失败的情况下，可以通过项目的变更控制委员会，讨论确定提交的缺陷报告是不是缺陷的问题。

2）缺陷信息共享

缺陷信息共享主要是指在测试执行过程中发现的缺陷，在不同项目成员之间进行共享。低级别的测试（例如：组件测试或集成测试）通常由开发人员完成；而高级别的测试（例如：系统测试或验收测试）由独立的测试团队完成。在开发人员正式提交版本的系统测试前，开发人员需要进行基本功能的测试，并提供关于版本的发布说明。由于在每个测试级别和不同的测试阶段都有可能发现缺陷，因此，在不同的项目成员之间进行缺陷信息的共享显得尤为重要。主要包括：

◆ 开发人员和测试人员之间的缺陷信息共享，例如：在开发人员提供的版本发布说明中，提供当前版本中存在的主要缺陷、对后续测试的影响以及建议的测试重点等。这些信息可以为测试人员进行的测试提供参考，同时可以避免测试人员提交一些已经存在的缺陷报告，从而避免浪费时间和精力，不断提高测试的有效性和效率。

◆ 测试人员之间的共享。在测试执行过程中，测试人员应该将提交的缺陷信息在项目的测试团队中进行共享，例如：通过邮件的形式，或者通过测试团队内部简短的会议等。特别是严重的缺陷可能会导致阻塞很多测试用例执行的缺陷，应该在测试团队内部发布该缺陷信息。通过在测试人员之间共享缺陷信息，可以在团队内部形成共同分析和解决问题的氛围，提高团队的测试热情和测试效率。

3）难以重现的缺陷

在测试执行过程中，经常会碰到一些不可重现或者很难重现的缺陷，特别是在进行系统的非功能性测试的时候，例如：稳定性测试、压力测试、满配置测试、兼容性测试等。在非功能性测试过程中发现的缺陷往往是严重程度比较高的，例如：系统不稳定、系统在不可预测的时候重启等。假如软件产品交付给用户之后，在用户现场或者系统运行过程中出现由于这样的缺陷而导致的失效，那么将会大大影响用户对产品的信心。

虽然有的组织和项目可能不统计无法重现或很难重现的缺陷，甚至忽视难以复现的缺陷。但是测试人员还是应该提交这种类型的缺陷报告，主要原因包括：

◆ 首先，在缺陷或者问题发现的时候，测试人员可以捕获一些异常的系统打印信息，这些信息能够帮助开发人员跟踪和定位缺陷发生的原因，从而有利于开发人员解决这种类型的缺陷。

◆ 其次，报告不可重现的缺陷可以形成项目的不可重现的缺陷数据库，定期浏览这些缺陷，并进行集中的分析，可能会在不同的缺陷描述中发现一些共同的或者可能有联系的信息，有助于问题的解决。

◆ 第三，报告不可重现的缺陷，如果该缺陷可能对用户的使用有较大的影响，测试人员需要在测试报告中描述这样的缺陷，告诉用户缺陷的表现，可能导致的问题，以及可能的补救方案。

◆ 第四，报告不可重现的缺陷，有助于测试人员和开发人员对这类问题和系统表现进行跟踪。

◆ 最后，测试人员在报告不可重现的缺陷时，应该在缺陷报告中明确提示该缺陷不可重现或者难以复现，避免在进度压力太大的情况下，开发人员将精力过多地放在这种类型的缺陷修复上。

4）清楚地报告而非解决缺陷

缺陷报告是测试过程中最重要的输出之一，编写良好的缺陷报告也是提高软件质量的重要保障。清楚的缺陷报告对测试团队而言具有重要的意义：

◆ 可以减少被开发人员拒绝从而打回来的缺陷数量。

◆ 加快缺陷修复的速度。

◆ 增加测试人员测试能力的可信度。

◆ 加强开发人员和测试人员之间的团队合作。

◆ 更加高效地提高软件质量。

因此，测试人员在提交缺陷报告的时候，应该从不同的方面保证缺陷报告的质量，一个好的缺陷报告应该具有下列特征：

◆ 精简的：缺陷的描述应该是清晰而简要的。在缺陷报告中要剔除不必要的无关的信息。在缺陷报告中包含所有缺陷相关的信息，并且确实是相关的，多余的信息只会使得缺陷的描述含糊不清。

◆ 正确的：提交的问题确实是一个缺陷。假如提交的缺陷最后证明是由于测试人员的理解错误或者配置错误引起的，可能使得测试人员在开发人员面前失去可信度，同时会对彼此之间的沟通带来一些影响。当然，不能因为害怕提交错误的缺陷，就对可能出现的缺陷视而不见，这比提交错误的缺陷影响更恶劣。因此，在提交缺陷报告之前，测试人员应该针对以下方面仔细检查：

• 确保搭建了正确的测试环境。
• 确保测试的版本是正式的测试版本。
• 确保不是前面执行的测试用例配置的信息干扰了测试结果。
• 确保网络通信没有问题。
• 确保测试人员正确地理解了产品的工作原理。
  

◆ 中立的：对缺陷及其特征进行实事求是的描述，避免夸张、幽默、讽刺的态度，避免在测试缺陷报告中带有个人感情色彩，因为这种感情色彩可能会影响团队之间的合作和沟通。

◆ 准确的：准确而明白地描述问题，不仅对做了什么进行描述，而应该对发生或者发现了什么进行描述。

◆ 隔离：尽量寻找简短的步骤复现缺陷，即将缺陷进行隔离，例如：缺陷所属模块、缺陷的触发条件等。对问题进行隔离定位，很大程度上体现了测试人员对测试对象的了解程度，同时可以提高测试效率和项目整体的效率。

◆ 推广：确定系统其他部分是否可能也存在同样的问题，以及使用不同的数据时是否也会出现这种问题等。测试人员在缺陷方面的推广有助于节约开发人员修正缺陷的时间，提高缺陷解决的效率。

◆ 复现：确定系统是否可以复现这个问题，以及复现该缺陷的步骤。对于能够复现的问题，应该提供简单的步骤和输入。对于难以复现的问题，尽量提供一些告警信息、日志信息；或者问题发现时，可以和开发人员一起进行跟踪调试和定位。对于实在无法复现的问题，在缺陷报告中应明确说明，并且在后续测试中持续跟踪。

◆ 证据：如同写测试用例需要测试条件一样，在缺陷报告中，需要提供测试的期望结果和实际得到的输出结果或者行为之间的差距，以及提供测试的依据。

◆ 评审：在提交缺陷报告之前，最好有一个有经验的测试人员阅读一遍。

测试人员在提交缺陷报告的时候，不要试图在缺陷报告中解决问题。因为测试人员和开发人员的角色和职责是不一样的，调试和解决问题是开发人员的主要职责。

5）明确缺陷优先级和严重程度

正确处理和区分缺陷的严重程度和优先级是所有软件开发和测试相关人员的一件重要的事情。缺陷的严重程度和优先级是含义不同但相互联系密切的两个概念，它们从不同方面描述了软件缺陷对软件质量、用户、开发过程的影响程度和处理方式。一般来说，严重程度高的缺陷具有较高的优先级。严重程度高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件的瑕疵，可以稍后处理。但是优先级和严重程度并不总是一一对应的，也存在优先级低但严重程度高的缺陷，或者优先级高但严重程度低的软件缺陷。

修改软件缺陷并不是纯技术的问题，有时候需要考虑软件版本发布和质量风险等因素。下面是关于缺陷严重程度和优先级设置方面的一些建议：

◆ 如果某个严重的缺陷只在非常极端的条件下产生，则可以将缺陷的优先级设置得比较低。

◆ 如果修正一个软件缺陷需要重新修改软件的整体架构，可能会产生更多的潜在缺陷，而且市场要求尽快发布软件版本，那么即使这个缺陷严重程度很高，也需要仔细考虑是否需要修改。

◆ 对于有些缺陷，可能它的严重程度很低，例如：界面单词拼写错误，但假如这是公司的名称或者商标，则这个缺陷的优先级就很高，必须尽快进行修复，因为这个关系到软件系统和公司在市场上的形象。

6）报告缺陷之前得到开发人员的确认

测试人员在测试环境中发现缺陷的时候，假如条件允许，在提交缺陷报告之前，可以和相关开发人员进行确认。当然，对于非常容易判断的功能性缺陷或者其他非常明确的缺陷类型，测试人员可以直接提交缺陷报告。而对于稳定性、功能行为表现复杂或者难以复现的缺陷，可以要求开发人员在测试现场确认发现的缺陷，这样可以提高项目的整体效率，有利于团队之间的合作：

◆ 首先，开发人员可以现场查看一些软件的打印信息和异常表现，有利于开发人员后面的缺陷复现和定位解决。

◆ 其次，开发人员可以帮助测试人员确认发现的问题是不是缺陷，避免测试人员提交一些不是缺陷的缺陷报告（例如：由于测试人员理解错误、配置错误等而导致的一些系统异常），同时避免开发人员在不是缺陷的缺陷报告上面浪费时间和精力，提高测试团队和开发团队的效率。

◆ 第三，有利于开发人员和测试人员的沟通，包括对软件系统的理解，从而在项目团队之间更好地合作。

7）缺陷分析和测试进度管理

缺陷分析是测试过程中最重要的测试活动之一，通过缺陷分析，可以了解项目的测试进展和软件产品的质量。缺陷分析也可以用来评估当前软件的可靠性，并且预测软件产品的可靠性变化。同时，缺陷的分析和评估也可以确定测试的重点，判断测试是否达到了测试出口准则等。

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

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

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

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

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

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

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

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

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

10）变更和变更的沟通

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

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

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

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

Zws丶森然

流程规范，沟通及时，才能出好的产品