软件测试培训
美国上市软件测试培训机构

400-111-8989

热门课程

测试人员遇到事应该怎么处理?

  • 时间:2018-01-15 13:14
  • 发布:软件测试培训
  • 来源:IT职场

问题1:比如我们软件有个帮助功能,是个H5页面,文案内容由运营提供,他们在后台可以随时改,后面发现一个文章的内容有误,就说测试漏测,然后测试肯定不背锅啊,就说应该找运营,然后就被说没有责任心,找借口,考核直接不及格

处理方式:

上线前会对发布的说明类内容做检查,算是我们测试范围之内的工作。如果我处在你的位置上,刚发现这个问题时,我会以退为进,告诉领导在这个问题上我们测试工作确实存在实物,当初的测试范围没有定义清楚,跟业务没有沟通好。--先把责任推到“沟通不到位”上面,另外“测试范围不清楚”一般领导会分摊责任。-再说,为了避免以后出现类似的情况,我跟业务做了约定,以后由我们共同检查。同时建议增加一个上线前验证的环节,专门检查这一类的问题。---这样说,也不会让人觉得遇到事情推脱责任,而是积极的反思工作中的不足,想法解决------有时候出了问题,不一定是坏事,利用好了也可以转化为自己的幸事。不要害怕“背锅”,有些责任可以主动承担。记住,出了质量问题,无论责任在哪里,先思考自己的工作是不是有可以改善的地方,在很多地方,测试部想提高话语权,想改善流程是很困难的,正好可以利用这些“事故”来推进工作。

问题2:测试的时候提出响应有点慢,然后产品经理说先不考虑性能,把功能上上去再改,然后上上去后其他部门的老大说慢,然后就是测试的责任

处理方式:很常见的情况。可以跟其他部门老大说明一下情况,不过从结果来看,测试做的确实有欠妥的地方,毕竟测试人员没有及时的把问题影响性跟干系人说清楚。记录好bug,bug未修复不关闭,如果有上线前评审,把这些问题拿出来让大家都知道。无论问题最后怎么样,测试人员先把自己的立场摆清楚。

问题3:开发人员不修改bug怎么办?

处理方式:

这个问题,从事软件测试这一行的绝大多数人都会遇到。 跟很多公司很多员工就这个问题进行过沟通?多数人对于开发人员不修改bug的现象可以举出很多例子,言语间也颇多不满、迷茫。但少有人能找到有效的解决方法。今天就说一下我的看法。 开发不改bug这个问题,有指标的方法,也有治本的措施,但没有一劳永逸的方案。不同的公司、不同的团队、不同的项目背景,采取的方法都可能不同。想解决问题,首先得研究问题,弄清楚开发为什么不修改bug。有些动作要从做事的角度考虑,也有的方法要从“人”方面下手。 下面我贴一下以前写的一篇文章,仅供参考。

程序员为什么不愿意修改bug? 无非是没时间,问题太小,重现不了,理解不了,在实际环境中不太可能发生,问题只出现在没有人用的非常特殊的设备配置上 ,改正缺陷的风险太大(特别是临近封版),不会影响程序的实际用户等。

我们测试人员为什么苦恼? 可能是觉得封版之前bug就应该全部解决(强迫症),也可能是觉得程序员没有理解bug的严重性,也许是bug明显违反规范,也可能是觉得缺陷肯定会影响到用户。

我们为什么难以说服程序员去修改那些bug? 说一说我看到的:测试员过于执着(bug并非必须修改),测试员不清楚说服程序员的技巧,测试员看轻自己(程序员一旦强势,测试员就低声下气),测试员技术水平低(不清楚修改bug的成本,可能只是加一个字段就能修复,开发说成本大,测试员就以为真的很大)

应对措施:本应跟先将问题分类,分析根源之后再一一作答。不过本文不是严谨的学术报告,笔者只谈几点一般性的措施

如何说服开发改正bug?

1、解释问题会怎样影响产品的正常使用? 2、会破坏什么数据? 3、用户如何经常遇到这个问题? 4、市面上类似产品的有关评论 5、指出类似的问题给客户带来的麻烦 6、多引用技术支持收集的数据 7、以前的版本通过了这个功能的测试 8、与其他项目干系人沟通。找出如果程序错误不修改受影响最大的人(或修改后受益的人),确定程序错误会给他们带来多大麻烦。让关心这个模块的人去说服。 列举一些场景,说明合理的用户在合理地使用程序时会遇到的程序错误,或产生的疑问。 9、补充做一些后续测试,寻找该程序错误更严重的后果,或寻找比在错误报告中所描述的更广环境下出现的情况。

补充

1、对于上面最后一点做点补充:如果程序员不修改某bug而我们决定反驳,不要完全依赖自己最初测试报告中的语言和信息。尽可能做一些补充测试,或列举更有效的例子,否则不仅浪费自己的时间,而且损害自己的信誉,影响自身的说服力。

3、不必坚持修改所有bug。项目经理可能会因为风险、费用等方面的原因,拒绝修改某些bug,这种情况下,我们测试员不需要坚持修改全部缺陷,除非能说明某缺陷可能引入的严重风险。

另外,笔者认为以下措施有助于推动bug的解决:

1、养成良好的报告编写习惯:比如在报告中描述问题出现的多种配置(需核实),或者在报告中预测某种可能并提供相关信息(特别是难以复现的bug) 。好的错误报告会推动问题的修正。

2、先等一等,在评审时看看大家反映,以静制动,提供补充信息。

3、多用事实和数据说话,例如“某个类似系统也有这个问题,客户因为那个问题,对程序的意见很大,因为客户平均每周要浪费XX时间在上面”

4、学习编程,理解bug产生的原因,助于写出更好的报告,以及理解bug修复成本。

注意点

1、关于利用bug管理系统监视程序员的表现。有的测试经理尝试用bug跟踪数据来促使程序员修改bug,比如利用数据反馈某程序员是否存在大量的bug未修改,或是否修改时间过长,或是否总是推迟修改。是否应该推行这种制度笔者不做评论,不过笔者建议推行时需注意引导程序员的情绪,否则很容易引起某些程序员的反感,他们会在某些时候大肆放大测试员的无能,或者发表不利于测试部的言论。不过这也是正常的,bug管理工具只要被用于行政或人事管理,而不是技术管理,就会产生这些问题。

2、关闭bug的权限应控制在测试员手中。除非经过测试员的验证,否则bug都不能闭环。在某些情况下,程序员会将未修复的bug置为“延期修改 ”、“非程序错误不予修改”“重复缺陷不予修改 ”,测试员需要且有义务对此提出质疑。

3、尽量避免“延期修改”变为“永不修改”。在很多公司中,bug标记为“延期修改”即意味着“永不修改”。为避免这种情况,有一种可行的措施是在下一版本做项目范围评审时即提出这些缺陷,那时候的进度压力最小,而且项目经理也最理智、最清醒。另外,发现“延期修改”的bug后,若持反对意见,建议尽快跟测试经理或者项目经理进行沟通。

4、bug修改后尽快验证,回归不通过后尽快跟程序员沟通,否则时间耽误越久,程序员记得的内容越少。

5、如果bug多次回归不通过,或在临近封版时发现严重缺陷,不仅要在缺陷管理工具中记录,更应该直接找到相应的程序员进行沟通。

问题4:怎么避免测试遗漏

处理方式:

1、很难完全避免遗漏 

2、提高用例覆盖度有两种主要方式,一是过程控制,一个是自身实力。 

 3、过程控制方面,比如团队中是否进行了有效的需求调研和评审,是否进行了有效的用例评审,沟通渠道(信息传递)是否顺畅等;

 4、自身实力方面,是否拥有足够的相关业务知识,对产品相关的业务和领域知识有足够理解; 自己是否拥有一套成熟的用例设计框架(思维框架); 

5、还可以通过以下几点提高覆盖率: 结对测试(交叉测试、定期更换测试项目); 网上查找类似项目的测试点; 总结该类项目的风险和重点; 多看书

以上内容来自达内软件测试培训,更多测试资讯,点击官网!

上一篇:大数据时代,数据与信息安全主要分为哪几类?
下一篇:软件测试业内人士对2017的回首2018的展望

谈一谈软件测试工程师的职业规划

软件测试工程师的入门级要求有哪些?

大家对于软件测试常见的误解有哪些

如何从零开始学习软件测试

选择城市和中心
贵州省

广西省

海南省