`
Fangrn
  • 浏览: 818150 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

开发人员为什么拒绝修改我的缺陷

阅读更多

缺陷是测试过程中测试人员的重要输出,它不仅是和其他项目利益相关者进行沟通的桥梁,也是证明测试人员测试能力的重要手段。但是,在实际的测试过程中,测试人员提交的缺陷常常会被开发人员以各种理由拒绝。

为 了减少被软件开发人员拒绝的缺陷的数目,我们首先需要了解为什么开发人员会拒绝测试人员提交的缺陷,或者说他们为什么不愿意花费时间和精力解决测试人员提 交的缺陷。本文将从几个不同的视角分析缺陷被拒绝的原因,从而有针对性的提出一些建议,帮助测试人员尽量减少被开发人员拒绝的缺陷的数目。根据笔者的经 验,开发人员拒绝研究和修改缺陷的原因是多方面的,例如:

°         开发人员无法复现缺陷(无法复现);

°         缺陷报告中提供的信息不足,或者复现缺陷需要奇怪而复杂的步骤(难以理解);

°         开发人员认为是系统的一个功能点,而测试人员认为是一个缺陷(缺陷还是功能点);

°         开发人员不理解测试人员的角色和职责定位(测试人员的角色);

1 )缺陷无法复现

开发人员拒绝研究和修复测试人员提交的缺陷的第一个可能理由是:这个缺陷我无法复现,或者这个问题在我的环境中并没有发现。

在 测试过程中,测试人员经常会碰到一些不可复现或者很难复现的问题,特别是在进行非功能性测试的时候,例如:稳定性测试、压力测试、满配置测试、兼容性测试 等。通常来说,这些难以复现的问题,其导致的结果一般都是比较严重的,例如:系统性能不稳定,系统随机重启等。同时,这些问题常常也是用户最关注的地方。 假如用户在使用过程中出现这样的严重问题,将会极大的降低用户对产品的信心。

即使是难以复现的问题,建议测试人员还是需要提交缺陷报告。只是,测试人员在提交缺陷报告之前,需要采取一些合适的策略和建议,尽量为开发人员定位和修复这样的问题提供合适的信息,帮助他们尽快解决问题。我的建议包括:

°         首先,测试人员养成这样的习惯:打开系统的调试窗口(假如系统提供),时时记录测试过程中系统的打印信息。发现系统的异常表现的时候,测试人员就可以捕获其中异常的系统打印信息,这些信息可以帮助开发人员跟踪和定位缺陷发生的原因,从而有利于开发人员解决这种类型的缺陷;

°         其 次,测试人员碰到系统的异常表现的时候,可以先判断该问题是否可能难以复现。假如觉得难以复现,测试人员可以先保留当前的测试环境,要求开发人员到现场来 定位和分析其中可能的原因。假如开发人员可以从当前的环境中分析得到可能的原因,那么测试人员编写缺陷报告就可以轻松得多;

°         第三,测试人员报告不可复现的缺陷的时候,应该在缺陷报告中明确告知开发人员不可复现或者难以复现,从而避免在有限的时间和资源情况下,开发人员过多的将精力放在这样的缺陷修改上面;

°         第四,建议测试人员提交难以复现的缺陷,组织内可以不断的收集和分析难以复现的缺陷数据库。定期浏览这些缺陷,并进行集中的分析,可能会在不同的缺陷描述中发现一些共同的或者可能有联系的信息,有助于问题的解决;

2 )缺陷报告难以理解

开发人员拒绝测试人员提交的缺陷的第二个可能理由是:缺陷报告中提供了太多的内容和信息,开发人员甚至不知道测试人员想说什么,也很难了解测试人员想阐述的问题是什么。

缺 陷报告是测试过程中测试人员的重要输出。很多的时候,项目利益相关者通过缺陷报告认识测试人员。好的缺陷报告可以为测试人员带来良好的声誉,而差的缺陷报 告可能会为利益相关者带来额外的工作。如果测试人员的缺陷报告,浪费了项目利益相关者太多的时间和资源,他们潜意识中就会抵制和拒绝他们的缺陷报告。

编写良好的缺陷报告是测试人员应该具备的几个基本技能。高效的缺陷报告,对测试人员而言具有重要的意义,除了可以减少被开发人员拒绝的缺陷数量,也有助于提高测试人员的可信度、改善开发人员和测试人员之间的合作关系。

好的缺陷报告是测试人员在测试过程中发现了什么,而不仅仅是告诉开发人员我们做了什么。这对于编写高质量的缺陷报告很重要。另外,我们在编写缺陷报告的时候,还应该使缺陷报告尽量具备以下特征:

°         精简的:缺陷的描述应该是清晰而简要的。首先在缺陷报告中剔除不必要的语言。其次,不要增加无关的信息。在缺陷报告中包含所有缺陷相关的信息,并且确实是相关的。多余的信息只会增加缺陷描述的含糊不清;

°         正确的:提交的问题确实是一个缺陷。假如提交的缺陷最后证明是由于理解错误或者配置错误引起的,测试人员将在开发人员面前失去可信度,同时会对彼此之间的沟通带来一些影响;

°         隔离:尽量寻找简短的步骤来复现缺陷,即将缺陷进行隔离。例如:哪个模块中发生了问题?是哪个输入条件触发了这个缺陷?是哪个动作引起了这个失效等。对问题的隔离定位能力,很大程度上可以为测试人员加分,同时可以提高大家的测试效率和项目整体的效率;

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

°         复 现:确定系统是否可以复现这个问题,需要什么样的步骤输入来复现这个问题。对于能够复现的问题,提供简单的步骤和输入。对于难以复现的问题,尽量提供一些 告警信息、日志信息给开发人员,或者问题发现时,可以和开发人员一道进行跟踪调试和定位。对于实在无法复现的问题,在缺陷报告中明确说明,并且在后续测试 中留意跟踪;

°         证据:如同写测试用例需要测试条件一样,在缺陷报告中,测试人员需要提供测试的期望结果和实际结果,参考文档是什么?;

除了上面的要求之外,测试人员在编写好缺陷报告之后,假如时间允许,可以请求有经验的测试人员或者测试经理,在提交缺陷报告之前阅读一遍。这有助于缺陷报告质量的提高。

3 )缺陷还是功能点

开发人员拒绝测试人员提交的缺陷的第三个可能理由是:他们认为这是一个正常的功能特性(或者功能点),而测试人员认为这是一个问题。

引起开发人员和测试人员对系统的同一个表现行为出现分歧的主要原因,可能是他们对系统的输入,例如:需求文档的理解不一样。通过合理的定义系统人员、开发人员和测试人员的角色和职责定义,可以较好的解决这样的问题。下面是三者关系的示意图:

 


1 研发人员关系示意图

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

4 )测试人员的角色

开发人员拒绝测试人员提交的缺陷的第四个可能理由是:产品的需求规格中并没有这样要求,需求规格中的功能和特性已经实现了。

引 起这个问题的原因主要是开发人员对测试人员角色和职责的定位不清楚。假如开发人员并不能很好的理解测试人员的工作,那么开发人员和测试人员之间在缺陷方面 的沟通也会存在一些问题。那么,测试人员的角色和职责应该是什么呢?我们认为测试应该是贯穿于整个软件开发生命周期,而不仅仅只是代码阶段之后的测试执行 活动。这里引入 Verification Validation 两个概念:

°         验证( Verification :通过检查和提供客观证据来证实指定的需求是否满足。也就是说,输入与输出之间的比较。也就是说,是检验软件是否已正确地实现了产品规格所定义的系统功能和特性,即“ Are you building the product right ”。

°         确认( Validation :通过检查和提供客观证据来证实特定功能或应用是否已经实现。在确认时,应考虑使用和应用的条件范围要远远大于输入时确定的范围。一般是由客户或代表客户的人执行。也就是说,是确认所开发的软件是否满足用户真正需求的活动,即“ Are you building the right product ”。

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

前面分别谈了开发人员拒绝修复测试人员提交的缺陷 4 个 主要原因,以及根据笔者的经验提出的一些建议。当然,测试过程中我们肯定还会碰到其他的一些原因,导致开发人员不愿意修复某些缺陷。不管是什么原因,都需 要我们测试人员具备良好的沟通能力、规范严谨的缺陷报告编写能力,以及通过良好的合作让开发人员更好的理解测试工作,从而达到更好更快的发现和修复缺陷, 实现高质量产品的及时发布。

  • 大小: 9.6 KB
分享到:
评论

相关推荐

    MANTIS缺陷管理流程

    在缺陷审批通过后,项目经理或高层领导会将缺陷分派给相应的开发人员或修改人员。缺陷分派需要考虑到缺陷的优先级、严重性和修复难度等因素。 修复缺陷 在缺陷分派后,开发人员或修改人员开始修复缺陷。修复缺陷...

    开发人员试用的testdirector手册,可以帮助测试人员培训开发人员快速使用TD

    - **REJECTED**:开发人员认为不是BUG,可以拒绝修改,设置为REJECTED。 - **CLOSED**:测试人员验证后,确认问题解决,设置为CLOSED。 这个简化流程旨在减少沟通成本,提升工作效率。开发人员在修复验证后将BUG...

    TestDirector_开发人员使用手册

    处理这些缺陷后,开发人员可以将状态更改为“打开”表示仍在处理,“已修改”并指派给测试人员以进行验证,或者设置为“不是问题”或“暂不修改”并通知项目负责人。 TestDirector还允许直接在界面上修改缺陷状态和...

    软件测试——缺陷密度、缺陷数据分析的重要性、缺陷数据分析的数据指标

    统计程序中新开发的和修改的代码行数 计算每千行的缺陷数=1000*缺陷总数/代码行数 缺陷数据分析的重要性 统计未修复的缺陷数目(特别是严重性高的缺陷),预计软件是否可以如期发布 分析缺陷的类型分布,发现存在...

    TestDirector 8.0开发人员使用手册

    - **Rejected**: 开发人员认为不是bug或重复的bug,拒绝修改。 - **Reopen**: 测试人员回测发现问题未修复,重新打开。 4. 开发人员修复缺陷后,将其状态更新为 "Fixed",并在Description中添加修复详情,点击 "...

    QC缺陷管理帮助文档

    3. **开发人员修改缺陷填写规范**: - 开发人员无权直接将缺陷状态设为“新建”,只能处理“打开”或“重新打开”的缺陷。 - 在修复缺陷后,需更新状态并等待测试验证。 4. **项目经理决定延期修改缺陷**: - ...

    测试缺陷管理规范

    3. **处置**:开发人员确认缺陷归属后,开始处理,并将缺陷状态改为“打开”,表示正在处理中。处理完毕后,需记录原因、解决方案以及是否存在其他潜在问题。 4. **解决**:开发人员解决问题后,填写解决方案,并将...

    缺陷管理流程图(缺陷管理工具介绍)

    4. **缺陷分配**:将缺陷报告分配给相应的开发人员,让他们负责修复。分配基于开发团队的技能和当前的工作负荷。 5. **缺陷重现和分析**:开发人员会尝试复现缺陷,理解其根本原因。这可能需要与测试人员协作,获取...

    高质量软件开发人员的五大习惯

    本文将详细介绍高质量软件开发人员必备的五大习惯,以期为读者提供一些实用的指导和启发。 首先,高质量软件开发人员的一个重要习惯是构造器实现最少的工作。构造器是创建对象时用来初始化对象状态的特殊方法。在...

    CMMI质量管理体系-软件测试缺陷管理.ppt

    * 缺陷修复:开发人员修改测试发现的缺陷,并提交成果物做再测试 * 缺陷验证:测试人员负责验证缺陷修复情况,且填写缺陷记录中相应信息 * 缺陷状态跟踪:项目组成员跟踪缺陷状态,并进行相应的处理 五、人员职责 ...

    CMMI质量管理体系软件测试缺陷管理ppt课件.ppt

    * 已拒绝:开发经理或者开发人员看到分配给自己的缺陷不是缺陷,将缺陷置为“已拒绝”状态 * 已修复:开发人员在开发环境对一个缺陷已经修复完 * 重新打开:测试人员看到缺陷处于“已修复”状态,经验证失败后,将...

    AC缺陷管理使用指南

    文档中的内容主要是针对QC缺陷管理使用ACExplorer工具的指南,目的是为了帮助软件开发人员和测试人员更好地使用这一工具进行缺陷跟踪和管理,从而提高软件开发的整体效率和质量。通过上述步骤的操作,用户可以熟练地...

    CMMI质量管理体系-软件测试缺陷管理ppt课件.ppt

    3. 缺陷修复:开发人员修改测试发现的缺陷,并提交成果物做再测试。 4. 缺陷验证:测试人员验证缺陷修复情况,并填写缺陷记录中相应信息。 缺陷管理人员职责 参与缺陷管理过程的人员角色职责包括: 1. 项目经理...

    软件缺陷分类标准[最新].doc

    软件缺陷分类标准是软件测试中一个非常重要的标准,它提供了软件缺陷的分类和定义,从而帮助测试人员、开发人员和开发经理更好地理解和处理软件缺陷。本文档将详细解释软件缺陷分类标准的各个方面,包括问题类型、...

    软件缺陷软件缺陷

    6. **修复策略**:开发人员根据缺陷描述和重现步骤进行修复。修复可能涉及修改代码、更新配置或重构部分系统。 7. **回归测试**:修复后,需执行回归测试以确保修复没有引入新的问题,并验证已修复的缺陷不会再次...

    软件测试——缺陷流程编写

    如果决定需要修复,缺陷将被分配给具体的开发人员("Assign Defect to Developer")。开发者会根据测试人员提供的信息重现问题,并尝试修复它。在修复后,开发者会进行内部测试,确保问题已得到解决,然后将修复的...

Global site tag (gtag.js) - Google Analytics