缺陷是测试过程中测试人员的重要输出,它不仅是和其他项目利益相关者进行沟通的桥梁,也是证明测试人员测试能力的重要手段。但是,在实际的测试过程中,测试人员提交的缺陷常常会被开发人员以各种理由拒绝。
为
了减少被软件开发人员拒绝的缺陷的数目,我们首先需要了解为什么开发人员会拒绝测试人员提交的缺陷,或者说他们为什么不愿意花费时间和精力解决测试人员提
交的缺陷。本文将从几个不同的视角分析缺陷被拒绝的原因,从而有针对性的提出一些建议,帮助测试人员尽量减少被开发人员拒绝的缺陷的数目。根据笔者的经
验,开发人员拒绝研究和修改缺陷的原因是多方面的,例如:
°
开发人员无法复现缺陷(无法复现);
°
缺陷报告中提供的信息不足,或者复现缺陷需要奇怪而复杂的步骤(难以理解);
°
开发人员认为是系统的一个功能点,而测试人员认为是一个缺陷(缺陷还是功能点);
°
开发人员不理解测试人员的角色和职责定位(测试人员的角色);
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
分享到:
相关推荐
被拒绝:项目组长将测试人员提交的缺陷指派给开发人员时,如果开发人员认为这个缺陷不是缺陷,就将状态设置为"被拒绝",意为测试人员提交的缺陷被开发人员拒绝 6.延期:有些时候,开发人员不能立即修复该缺陷,需要...
统计程序中新开发的和修改的代码行数 计算每千行的缺陷数=1000*缺陷总数/代码行数 缺陷数据分析的重要性 统计未修复的缺陷数目(特别是严重性高的缺陷),预计软件是否可以如期发布 分析缺陷的类型分布,发现存在...
之外,我也会探讨开发人员拒绝修改缺陷的原因,以及他们可能不认同某个缺陷是BUG的情况。同时,我们还将为你解析缺陷修改的决策过程,让你了解软件缺陷修复背后的复杂性和挑战性。 无论你是软件测试工程师、开发...
一.缺陷常用字段说明 二.缺陷管理流程图 三.开发人员修改缺陷填写规范 四.项目经理决定延期修改缺陷
(3)完善的权限控制:预设测试人员、开发人员、项目经理3个角色,每个角色的查看权、录入权、修改权、删除权均可设定,且细化到每一个字段。可根据需要设定其它角色,因此您完全可以让客户、技术支持也加入进来,...
按照尽早进行测试的原则,测试人员应该在需求阶段就介入,并贯穿软件开发的全过程。就测试过程本身而言,应该包含以s下几个阶段。 -测试需求的分析和确定。 -测试计划。 -测试设计。 -测试执行。 -...
用于统计Redmine的缺陷数量,按开发员和测试人员两种角度。下载后修改数据库链接后和统计日期即可使用。
开发人员:主页、个人中心(我的待办、我的已办)、缺陷管理(列表) 测试人员:主页、个人中心(我的待办、我的已办)、缺陷管理 系统管理员:个人中心(我的待办、我的已办)、缺陷管理、项目管理、用户管理、角色...
缺陷跟踪管理系统在现代软件开发中已经占据了很重要的位置,每一个软件组织都 知道必须妥善处理软件中的缺陷,这是关系到软件组织生存、发展的质量根本。 从系统考虑,应将缺陷跟踪管理纳入到项目管理信息系统之中,...
(3)完善的权限控制:预设测试人员、开发人员、项目经理3个角色,每个角色的查看权、录入权、修改权、删除权均可设定,且细化到每一个字段。可根据需要设定其它角色,因此您完全可以让客户、技术支持也加入进来,...
同时,他们还需要与产品经理、开发人员、架构师等相关人员进行交流,以获取更深入的需求理解。 测试计划编写:根据需求分析的结果,测试团队或测试领导/测试经理会开始编写测试计划。测试计划包括估算测试所需资源...
作为调试员身份登录系统之后,调试员将会查看到所有所负责的软件缺陷信息,在对软件项目进行测试之后,将软件的缺陷进行详细的描述,然后,选择具体的解决方案的人员进行记录,最后提交信息,解决方案人员会查看到...
1、发现——打开:测试人员找到软件缺陷并将软件缺陷提交给开发人员; 2、打开——修复:开发人员再现、修复缺陷,然后提交测试人员去验证; 3、修复——关闭:测试人员验证修复过的软件,关闭已不存在的缺陷。 但是...
该项目为web应用,使用SpringBoot+Vue的前后端分离架构进行开发。 具有注册、登录、修改个人信息、项目管理、人员管理、缺陷管理等功能。 实际开发时间约两周,从2019-10-7到2019-10-20。 由于本身身单力薄,时间和...
软件缺陷管理系统(农药)项目简介该项目为web应用,使用SpringBoot + Vue的前拆分分离架构进行开发。具有注册,登录,修改个人信息,项目管理,人员管理,缺陷管理等功能。实际开发时间约两周,从2019-10-7到2019-...
深入剖析修改遗留代码的各种方法和策略,从理解遗留代码、为其编码测试、重构及增加特性等方面给出大量实用建议,是所有程序开发人员必读之作。 理解修改软件的机制:添加特性、修正缺陷、改进设计、优化性能把...
- 该工程的主要好处是解决开发人员编写重复的代码, - 强制开发人员使用规范的编程模式和代码注解, - 提高代码的可维护性和阅读性, - 降低了代码的不规范性和因个人编程缺陷引起的不必要风险, - 提高代码质量...
当FPT应用于Web开发时,界面设计人员可以和程序开发人员同步开发一个遵循MVC架构的Web站点,也就是说,页面设计人员可以只关注页面的显示效果,而由程序开发人员关注业务逻辑编码。FPT将.NET程序代码从Web页面中分离...
当项目出现Bug时,软件测试人员可以把他提交到缺陷跟踪系统,指定程序员修改进行修改或者由哪个程序员自己认领这个任务,同时可以跟踪这个Bug的状态等等。如果换一种看法,Bugzilla也可以用作任务管理,那么这里的...
管理员 ...查看缺陷信息 提出解决方案 所需开发环境: 开发语言:Java 框架:ssm JDK版本:JDK1.8 服务器:tomcat7+ 数据库:mysql 5.7+ 数据库工具:Navicat11+ 开发软件: idea Maven包:Maven3.3.9+