软件测试完成后,还有BUG,是测试人员的问题吗?

在知乎上看到一个很有意思的问题“软件测试完后,还有BUG,是测试人员的问题吗?”

在这里插入图片描述

相信很多测试的小伙伴也都遇到过这样的情况,往往产品上线,只要出现bug,成为“背锅侠”。

测试人员在工作中经常打交道的肯定是开发和产品经理,开发将程序写出来,测试员进行测试。软件测试完成后,产品才能生产,在这过程中,难免会遇到软件会出现问题的情况。那么你肯定听过这些话:

“这么明显的bug你都测不出来吗?”

“为啥这个功能还没测完就上线了?”

“研发时间不够,你压缩一下测试时间”

“这个bug和开发没关系,注意看需求”

听到这些话,相信你分分钟高血压,这个锅不知不觉就“甩”到你身了。

问题的关键来了,很多测试员就会出现这种疑问:软件测试完后,还有Bug,责任全都在测试吗?

举个例子测试攻城狮们就会明白,不是所有的锅都得测试背

1、假设是软件版本更新,开发人员在进行影响分析时漏掉了可能会影响的一个功能,而测试也没有测到这个功能,恰恰这个功能上线出了问题,那没说的,开发的责任;

2、软件开发延期导致原本两轮的测试变为一轮测试,测试不充分导致出现BUG,这应该是整个项目组的责任;

3、软件按时提交测试,BUG出现在测试覆盖范围内,那么就是测试的责任;

4、测试BUG较多,测试部门要求延期上线,结果客户或者领导压下来,说必须按时上线,你说这是谁的问题?

所以,软件测试完后,还有Bug,不一定都是测试的锅,首先要清楚的知道是什么原因导致出现的bug,所以这个时候就需要有人来组织这个Bug的责任认定和后续改进。

线上Bug的讨论一般有如下这些内容:

1、Bug的产生原因,仔细地分析Bug为什么会产生,这个环节很重要,因为这个环节弄清楚以后,责任认定就清楚了。

2、Bug的责任认定,一般来说,除了那些责任真的很清晰的Bug之外,很多Bug都是开发、测试、策划、项目经理共责的,为了团队的团结,也没有必要去讨论哪个团队负主要责任。

3、Bug影响范围,分析这个Bug对于用户造成的影响。

4、改进措施,在改进措施这一项中,可以把以后如何避免类似Bug的措施写进去,并在任务系统建立任务,指定专门的人跟进。

其实,说到底,还是因为职责划分不清晰导致的“背锅”。

那再来说下项目组实际Bug的责任认定吧:

1、如果测试时间还是比较充足,测试用例有写,但是还是漏测的,那就是测试的责任。

测试用例没有覆盖,测试用例覆盖了却没有执行,各有不同的偏重点,前者参与评审的相关人员都有责任,后者测试组的完全责任,PM也有对应责任。

2、如果测试时间不充足,测试用例有写,但是因为时间不足而降低回归测试范围,导致漏测的,那一般是项目组各个角色共责的。

3、如果有开发修改了功能没有通知测试人员,导致线上漏测的,那就是开发的责任。

4、如果策划人员在回归测试阶段还提了需求变更,在测试人员明确告知风险的情况下还坚持要上需求变更的,那就是策划的责任。

5、需求覆盖不到的地方,描述不清楚的地方,需求,设计和测试都要承担一定的责任,需求的责任最重。说需求人员的责任大家都容易理解,为什么说设计和测试还有PM都有责任,是因为需求的评审是需要设计和测试参与的,角度不同,具体这里就不展开了。

除非判断就是需求采集中的重大缺陷,否则设计和测试都有关联的次要责任。

6、设计过程,开发过程没有实现,需求检查到了,设计和开发却没有弥补。设计和开发的责任,PM责任最大,监管不到位。

7、交付部署中出现的问题,版本拿错的责任,一般在于PM,配置管理员和测试经理,也有可能是因为没有足够明确的制度造成了混乱,这样需要部门经理或者更高层的人员来牵头负责。版本拿对了,安装过程出错,交付部署人员的责任最大,项目经理次之。

对于测试人员来说,测试阶段如果因为时间缺少、需求变更频繁等原因导致回归测试范围不足的,一定要尽早跟项目组正式地发邮件沟通情况,让大家尽早知晓风险,这样出现线上Bug的时候,项目组其他人员就不会认为测试工作没做到位。

测试人员如何有效避免“背锅”呢?

1、留出足够的测试时间

要保证测试时间,从流程上就要做起,说明测试的重要性,我看很多测试对自己的重要程度一直没认识到。在项目排期时,就要定够足够的测试时间(一般都是给一点冗余时间,以处理突发事件)。如果说因为特殊情况导致测试时间不够,比如开发没有按预期提测,产品需求变更,也要勇于提出或者延期发版,或者减少功能,以保证自己测试时间。如果说这两点都不能保证,则在测试报告中写明,由于xxx情况,导致测试时间不足,所引起无法完全覆盖。

2、做好数据备份。凡事不要口头沟通。

我看有些人背锅,明明测过了,提过bug,但是线上又出现了人家说你提的bug 呢?你说我只是和开发说了一句…呵呵,空口无凭。提bug 的时候,不要途一时之快,不写bug口头沟通,这样没事的时候你好我好大家好,出了事,你想甩锅都没办法甩。包括前面测试的版本包,都备份下来。如果确实是开发后面改动引起的问题。你可以把前面的版本包拿出来验证,如果没问题,则可甩部分锅给开发(这里部分看能力,如果是我以前老大,锅就全甩过去了)

3、写好测试报告。

对于有风险的内容,测试报告里一定要写清楚,比方说前面说的时间不够。又或者是一些情况,测试环境不好验证。注明后,发给团队,团队人周知,并且是项目负责人拍版可以后再进行发版。测试报告不要随便写写就算了,非常重要。

4、甩锅给开发,产品没关系,不要甩锅给同是测试组员,或者手下,否则后患无穷。

我就碰见过一个甩锅给手下的老大,最后闹的两个人都不说话,有事就发邮件沟通。毕竟测试同学都是小伙伴,谁是我们的朋友,谁是我们的敌人,还是要分清楚的。滴水不漏的甩锅给手下,同事,最后难免搞的自己孤家寡人。事实上,我碰见我的组员出一些问题,都会主动帮他分担部分责任的,让他感觉我在挺他。这样才能保证测试团队的凝聚力。

总结

保证软件高质量,并非只是测试人员的责任,软件质量体现在功能质量、结构质量和过程质量三个方面,对产品质量负责,意味着要对这三方面共同负责。当出现Bug时,对于企业来说,问题不解决,只是纠缠问题是谁的责任,公司会被这些人直接拖垮,这时候对于企业来说最重要的就是解决问题!所以对于产品质量,最理想的状态还是做到人人都为产品质量负责,为了达到这个目标,我们需要建立一种重视质量的文化,每个人才会确确实实地对质量负责。

身为一名IT技术人员磨练自己的技术是必不可少的,欢迎加入测试交流群(313782132),可以与大牛在线随时讨论自己感兴趣的话题,让自己用最少的时间学到最多的东西。

在此基础上,可以进行一些可靠性,容错性,兼容性等用例的设计,测试下软件的稳定性。

点击我,加入我们吧!群内有许多来自一线的技术大牛,也有在小厂或外包公司奋斗的码农,我们致力打造一个平等,高质量的软件测试交流圈子,不一定能短期就让每个人的技术突飞猛进,但从长远来说,眼光,格局,长远发展的方向才是最重要的。

35岁中年危机大多是因为被短期的利益牵着走,过早压榨掉了价值,如果能一开始就树立一个正确的长远的职业规划。35岁后的你只会比周围的人更值钱

  • 9
    点赞
  • 32
    收藏
    觉得还不错? 一键收藏
  • 6
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值