哪些缺陷开发人员容易拒绝修改？

缺陷是测试过程中测试人员的重要输出，它不仅是和其他项目利益相关者进行沟通的桥梁，也是证明测试人员测试能力的重要手段。但是，在实际的测试过程中，测试人员提交的缺陷常常会被开发人员以各种理由拒绝。
为了减少被软件开发人员拒绝的缺陷的数目，首先需要了解为什么开发人员会拒绝测试人员提交的缺陷，或者说他们为什么不愿意花费时间和精力解决测试人员提交的缺陷。本文将从几个不同的视角分析缺陷被拒绝的原因，从而有针对性的提出一些建议，帮助测试人员尽量减少被开发人员拒绝的缺陷的数目。开发人员拒绝研究和修改缺陷的原因是多方面的，例如：

1. 开发人员无法复现缺陷（无法复现）；
2. 缺陷报告中提供的信息不足，或者复现缺陷需要奇怪而复杂的步骤（难以理解）；
3. 开发人员认为是系统的一个功能点，而测试人员认为是一个缺陷（缺陷还是功能点）；
4. 开发人员不理解测试人员的角色和职责定位（测试人员的角色）；

1）缺陷无法复现
开发人员拒绝研究和修复测试人员提交的缺陷的第一个可能理由是：这个缺陷我无法复现，或者这个问题在我的环境中并没有发现。
在测试过程中，测试人员经常会碰到一些不可复现或者很难复现的问题，特别是在进行非功能性测试的时候，例如：稳定性测试、压力测试、满配置测试、兼容性测试等。通常来说，这些难以复现的问题，其导致的结果一般都是比较严重的，例如：系统性能不稳定，系统随机重启等。同时，这些问题常常也是用户最关注的地方。假如用户在使用过程中出现这样的严重问题，将会极大的降低用户对产品的信心。
即使是难以复现的问题，建议测试人员还是需要提交缺陷报告。只是，测试人员在提交缺陷报告之前，需要采取一些合适的策略和建议，尽量为开发人员定位和修复这样的问题提供合适的信息，帮助他们尽快解决问题。我的建议包括：

1. 首先，测试人员养成这样的习惯：打开系统的调试窗口（假如系统提供），时时记录测试过程中系统的打印信息。发现系统的异常表现的时候，测试人员就可以捕获其中异常的系统打印信息，这些信息可以帮助开发人员跟踪和定位缺陷发生的原因，从而有利于开发人员解决这种类型的缺陷；
2. 其次，测试人员碰到系统的异常表现的时候，可以先判断该问题是否可能难以复现。假如觉得难以复现，测试人员可以先保留当前的测试环境，要求开发人员到现场来定位和分析其中可能的原因。假如开发人员可以从当前的环境中分析得到可能的原因，那么测试人员编写缺陷报告就可以轻松得多；
3. 第三，测试人员报告不可复现的缺陷的时候，应该在缺陷报告中明确告知开发人员不可复现或者难以复现，从而避免在有限的时间和资源情况下，开发人员过多的将精力放在这样的缺陷修改上面；
4. 第四，建议测试人员提交难以复现的缺陷，组织内可以不断的收集和分析难以复现的缺陷数据库。定期浏览这些缺陷，并进行集中的分析，可能会在不同的缺陷描述中发现一些共同的或者可能有联系的信息，有助于问题的解决；

2）缺陷报告难以理解
开发人员拒绝测试人员提交的缺陷的第二个可能理由是：缺陷报告中提供了太多的内容和信息，开发人员甚至不知道测试人员想说什么，也很难了解测试人员想阐述的问题是什么。
缺陷报告是测试过程中测试人员的重要输出。很多的时候，项目利益相关者通过缺陷报告认识测试人员。好的缺陷报告可以为测试人员带来良好的声誉，而差的缺陷报告可能会为利益相关者带来额外的工作。如果测试人员的缺陷报告，浪费了项目利益相关者太多的时间和资源，他们潜意识中就会抵制和拒绝他们的缺陷报告。
编写良好的缺陷报告是测试人员应该具备的几个基本技能。高效的缺陷报告，对测试人员而言具有重要的意义，除了可以减少被开发人员拒绝的缺陷数量，也有助于提高测试人员的可信度、改善开发人员和测试人员之间的合作关系。
好的缺陷报告是测试人员在测试过程中发现了什么，而不仅仅是告诉开发人员我们做了什么。这对于编写高质量的缺陷报告很重要。另外，我们在编写缺陷报告的时候，还应该使缺陷报告尽量具备以下特征：

1. 精简的：缺陷的描述应该是清晰而简要的。首先在缺陷报告中剔除不必要的语言。其次，不要增加无关的信息。在缺陷报告中包含所有缺陷相关的信息，并且确实是相关的。多余的信息只会增加缺陷描述的含糊不清；
2. 正确的：提交的问题确实是一个缺陷。假如提交的缺陷最后证明是由于理解错误或者配置错误引起的，测试人员将在开发人员面前失去可信度，同时会对彼此之间的沟通带来一些影响；
3. 隔离：尽量寻找简短的步骤来复现缺陷，即将缺陷进行隔离。例如：哪个模块中发生了问题？是哪个输入条件触发了这个缺陷？是哪个动作引起了这个失效等。对问题的隔离定位能力，很大程度上可以为测试人员加分，同时可以提高大家的测试效率和项目整体的效率；
4. 推广：确定系统其他部分是否可能也存在同样的问题，以及使用不同的数据时是否也会出现这种问题等等。测试人员在缺陷方面的推广能力，可以帮助节约开发人员修改缺陷的时间，同时提高缺陷解决的效率；
5. 复现：确定系统是否可以复现这个问题，需要什么样的步骤输入来复现这个问题。对于能够复现的问题，提供简单的步骤和输入。对于难以复现的问题，尽量提供一些告警信息、日志信息给开发人员，或者问题发现时，可以和开发人员一道进行跟踪调试和定位。对于实在无法复现的问题，在缺陷报告中明确说明，并且在后续测试中留意跟踪；
6. 证据：如同写测试用例需要测试条件一样，在缺陷报告中，测试人员需要提供测试的期望结果和实际结果，参考文档是什么？

除了上面的要求之外，测试人员在编写好缺陷报告之后，假如时间允许，可以请求有经验的测试人员或者测试经理，在提交缺陷报告之前阅读一遍。这有助于缺陷报告质量的提高。
3）缺陷还是功能点
开发人员拒绝测试人员提交的缺陷的第三个可能理由是：他们认为这是一个正常的功能特性（或者功能点），而测试人员认为这是一个问题。
引起开发人员和测试人员对系统的同一个表现行为出现分歧的主要原因，可能是他们对系统的输入，例如：需求文档的理解不一样。通过合理的定义系统人员、开发人员和测试人员的角色和职责定义，可以较好的解决这样的问题。下面是三者关系的示意图：

图1 研发人员关系示意图

图1说明了系统人员是软件开发和软件测试的基础和核心。通过系统人员将产品的用户需求转化为详细的需求规格说明。在需求规格说明基线化后，软件人员以此作为基础进行系统概要设计和详细设计，而测试人员根据需求规格说明来进行软件测试策略和详细测试用例的设计。同时，软件人员和软件测试人员都需要和系统人员紧密合作和交流，将各个阶段的开发活动和测试活动得到的信息反馈给系统人员，来完善和优化系统需求规格说明。按照这样角色和职责的定义，假如开发人员和测试人员针对某个产品的表形行为有分歧的时候，可以通过系统人员来做最后的决定。通过软件开发过程控制和管理，开发人员和测试人员就可以较好的避免纠缠“是缺陷还是功能点”此类问题，从而提高我们的测试效率，同时也可以更好的实现项目利益相关者之间的沟通。

4）测试人员的角色
开发人员拒绝测试人员提交的缺陷的第四个可能理由是：产品的需求规格中并没有这样要求，需求规格中的功能和特性已经实现了。
引起这个问题的原因主要是开发人员对测试人员角色和职责的定位不清楚。假如开发人员并不能很好的理解测试人员的工作，那么开发人员和测试人员之间在缺陷方面的沟通也会存在一些问题。那么，测试人员的角色和职责应该是什么呢？我们认为测试应该是贯穿于整个软件开发生命周期，而不仅仅只是代码阶段之后的测试执行活动。这里引入Verification和Validation两个概念：

1. 验证（Verification）：通过检查和提供客观证据来证实指定的需求是否满足。也就是说，输入与输出之间的比较。也就是说，是检验软件是否已正确地实现了产品规格所定义的系统功能和特性，即“Are you building the product right”。
2. 确认（Validation）：通过检查和提供客观证据来证实特定功能或应用是否已经实现。在确认时，应考虑使用和应用的条件范围要远远大于输入时确定的范围。一般是由客户或代表客户的人执行。也就是说，是确认所开发的软件是否满足用户真正需求的活动，即“Are you building the right product”。

根据Verification和Validation两个概念，我们可以看到，测试人员除了要验证产品是否正确实现了需求规格说明之外，他还需要站在客户的角度，分析产品是否真的是客户所要求的。因此，测试过程中，测试人员除了报告功能性的缺陷之外，特别需要注意一些非功能的特性，特别是用户所关注而需求规格中可能并没有明确定义的要求，例如：产品是否容易使用，图形界面是否布局合理等。

前面分别谈了开发人员拒绝修复测试人员提交的缺陷4个主要原因，以及根据笔者的经验提出的一些建议。当然，测试过程中我们肯定还会碰到其他的一些原因，导致开发人员不愿意修复某些缺陷。例如：项目进度紧张，在当前版本中不修复，延期到后续版本中修复；当前技术无法实现，或者实现需要对系统架构实现大的变更，可能引入更大的风险。不管是什么原因，都需要我们测试人员具备良好的沟通能力、规范严谨的缺陷报告编写能力，以及通过良好的合作让开发人员更好的理解测试工作，从而达到更好更快的发现和修复缺陷，实现高质量产品的及时发布。

[文章来源]：专注于测试能力改进