前言：
前几天我和两个做网络运维的朋友吃饭聊天，聊着聊着谈到了工作当中背锅的经历。
第一个朋友谈到了这样的一件事情：A客户J业务系统中断了十几个小时，他公司负责X部网络运维的同事配合J部排查故障原因，在没有得到客户允许下，私自改动了自身运维的网络设备配置，业务恢复正常。而事后业务部门追责故障原因，却说是他们负责运维的设备出现问题导致的。
另一个小伙伴的剧情更加精彩，他讲到：他们公司负责B企业网络运维项目，网络设备贴标签工作由第三方机房运维企业负责。某天客户领导检查机房网络设备，发现部分设备标签未贴。第三方机房运维人员当场甩锅，说是他公司未提供标签数据信息给他们，导致网络设备标签没打。最终结果成了客户向项目经理投诉他们现场运维工程师工作不到位。
就一句话：工作中没背过锅的，不足以谈人生，生活已经如此艰难，再背个锅简直难上加难有木有。
在这里插入图片描述
不过有句老话说的好：吃亏是福！如果你今天是背锅侠明天说不定就成了甩锅侠，没有啦，开个玩笑，我知道背锅是听让人难受的，但是有时候正是一次背锅，后面你就少踩很多坑。
正文：
我相信很多测试的小伙伴和我一样也都遇到过这样的情况，往往产品上线，只要出现bug，成为“背锅侠”。测试人员在工作中经常打交道的肯定是开发和产品经理，开发将程序写出来，测试员进行测试。软件测试完成后，产品才能生产，在这过程中，难免会遇到软件会出现问题的情况。那么你肯定听过这些话：
a.“这么明显的bug你都测不出来吗？”
b.“为啥这个功能还没测完就上线了？”
c .“研发时间不够，你压缩一下测试时间”
d.“这个bug和开发没关系，注意看需求”
听到这些话，相信你分分钟高血压，这个锅不知不觉就“甩”到你身了。
在这里插入图片描述
那么就有个非常严肃的问题来了，软件都测试完成后了，还有Bug，责任全都在测试吗？！在这个这个。。。。，当然不是啊，下面举了例子和大家好好讲讲，到最后你会发现不是所有的锅都得测试背。
在这里插入图片描述
一.一定不是测试责任的情况：
a：假设是软件版本更新，开发人员在进行影响分析时漏掉了可能会影响的一个功能，而测试也没有测到这个功能，恰恰这个功能上线出了问题，那没说的，开发的责任；
b：软件开发延期导致原本两轮的测试变为一轮测试，测试不充分导致出现BUG，这应该是整个项目组的责任；
c：软件按时提交测试，BUG出现在测试覆盖范围内，那么就是测试的责任；
d：测试BUG较多，测试部门要求延期上线，结果客户或者领导压下来，说必须按时上线，你说这是谁的问题？
所以，软件测试完后，还有Bug，不一定都是咱们做测试的锅，首先要清楚的知道是什么原因导致bug的产生，所以这个时候就需要有人来组织这个Bug的责任认定和后续改进。
二.线上Bug的讨论一般有如下这些内容：
a、Bug的产生原因，仔细地分析Bug为什么会产生，这个环节很重要，因为这个环节弄清楚以后，责任认定就清楚了。
b、Bug的责任认定，一般来说，除了那些责任真的很清晰的Bug之外，很多Bug都是开发、测试、策划、项目经理共责的，为了团队的团结，也没有必要去讨论哪个团队负主要责任。
c、Bug影响范围，分析这个Bug对于用户造成的影响。
d、改进措施，在改进措施这一项中，可以把以后如何避免类似Bug的措施写进去，并在任务系统建立任务，指定专门的人跟进。
其实，说到底，还是因为职责划分不清晰导致的“背锅”。
三.那再来说下项目组实际Bug的责任认定吧：
a、如果测试时间还是比较充足，测试用例有写，但是还是漏测的，那就是测试的责任。
测试用例没有覆盖，测试用例覆盖了却没有执行，各有不同的偏重点，前者参与评审的相关人员都有责任，后者测试组的完全责任，PM也有对应责任。
b、如果测试时间不充足，测试用例有写，但是因为时间不足而降低回归测试范围，导致漏测的，那一般是项目组各个角色共责的。
c、如果有开发修改了功能没有通知测试人员，导致线上漏测的，那就是开发的责任。
d、如果策划人员在回归测试阶段还提了需求变更，在测试人员明确告知风险的情况下还坚持要上需求变更的，那就是策划的责任。
e、需求覆盖不到的地方，描述不清楚的地方，需求，设计和测试都要承担一定的责任，需求的责任最重。说需求人员的责任大家都容易理解，为什么说设计和测试还有PM都有责任，是因为需求的评审是需要设计和测试参与的，角度不同，具体这里就不展开了。
除非判断就是需求采集中的重大缺陷，否则设计和测试都有关联的次要责任。
f、设计过程，开发过程没有实现，需求检查到了，设计和开发却没有弥补。设计和开发的责任，PM责任最大，监管不到位。
g、交付部署中出现的问题，版本拿错的责任，一般在于PM，配置管理员和测试经理，也有可能是因为没有足够明确的制度造成了混乱，这样需要部门经理或者更高层的人员来牵头负责。版本拿对了，安装过程出错，交付部署人员的责任最大，项目经理次之。
对于测试人员来说，测试阶段如果因为时间缺少、需求变更频繁等原因导致回归测试范围不足的，一定要尽早跟项目组正式地发邮件沟通情况，让大家尽早知晓风险，这样出现线上Bug的时候，项目组其他人员就不会认为测试工作没做到位。
四.那么重点来了测试人员如何有效避免“背锅”呢?
a、留出足够的测试时间
要保证测试时间，从流程上就要做起，说明测试的重要性，我看很多测试对自己的重要程度一直没认识到。在项目排期时，就要定够足够的测试时间(一般都是给一点冗余时间，以处理突发事件)。如果说因为特殊情况导致测试时间不够，比如开发没有按预期提测，产品需求变更，也要勇于提出或者延期发版，或者减少功能，以保证自己测试时间。如果说这两点都不能保证，则在测试报告中写明，由于xxx情况，导致测试时间不足，所引起无法完全覆盖。
b、做好数据备份。凡事不要口头沟通。
我看有些人背锅，明明测过了，提过bug，但是线上又出现了人家说你提的bug 呢？你说我只是和开发说了一句…呵呵，空口无凭。提bug 的时候，不要途一时之快，不写bug口头沟通，这样没事的时候你好我好大家好，出了事，你想甩锅都没办法甩。包括前面测试的版本包，都备份下来。如果确实是开发后面改动引起的问题。你可以把前面的版本包拿出来验证，如果没问题，则可甩部分锅给开发(这里部分看能力，如果是我以前老大，锅就全甩过去了)
c、写好测试报告。
对于有风险的内容，测试报告里一定要写清楚，比方说前面说的时间不够。又或者是一些情况，测试环境不好验证。注明后，发给团队，团队人周知，并且是项目负责人拍版可以后再进行发版。测试报告不要随便写写就算了，非常重要。
d、甩锅给开发，产品没关系，不要甩锅给同是测试组员，或者手下，否则后患无穷。
我就碰见过一个甩锅给手下的老大，最后闹的两个人都不说话，有事就发邮件沟通。毕竟测试同学都是小伙伴，谁是我们的朋友，谁是我们的敌人，还是要分清楚的。滴水不漏的甩锅给手下，同事，最后难免搞的自己孤家寡人。事实上，我碰见我的组员出一些问题，都会主动帮他分担部分责任的，让他感觉我在挺他。这样才能保证测试团队的凝聚力
在这里推荐一个软件测试交流群，qq:642830685,群中会不定期的分享软件资源，测试面试题以及测试行业资讯，大家可以在群中积极交流技术，还有大佬为你答疑解惑。
五.写在最后：
不要沮丧，不必惊慌，做努力爬的蜗牛或坚持飞的笨鸟，我们试着长大，一路跌跌撞撞，然后遍体鳞伤。坚持着，总有一天，你会站在最亮的地方，活成自己曾经渴望的模样。一些事情，当你选择放弃的时候，不是因为你不够坚定和执着，也不是因为你懦弱，而是因为必须选择面前给自己一个台阶。
所以朋友们当你面对生活中的不快时，努力调整自己，朝着心中所念所想，加油！
在这里插入图片描述
看完文章的小伙伴们不要忘记举起你那可爱的小手给我点个赞，你的点赞是我更文的不竭动力，笔芯。