更好的团队合作之缺陷篇：有效沟通的10个建议

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

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

　　1)缺陷的认定

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

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

　　图1项目开发的三种角色

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

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

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

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

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

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

　　2)缺陷信息共享

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

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

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

　　3)难以重现的缺陷

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

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

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

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

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

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