链接：https://www.zhihu.com/question/42151352/answer/106933562
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
如果软件上线后出现了重大的Bug，产品的各个角色肯定都有压力，这种情况下，首先需要有人来组织这个Bug的责任认定和后续改进，这个角色一般是PM，不过，对于有一些团队，也可以由最关心质量的测试团队来发起。如果没人发起，建议测试团队一定要主动地去发起这类总结，因为这个也是产品质量保证的重要环节。
线上Bug的讨论一般有如下这些内容：
1、Bug的产生原因，仔细地分析Bug为什么会产生，这个环节很重要，因为这个环节弄清楚以后，责任认定就清楚了。
2、Bug的责任认定，一般来说，除了那些责任真的很清晰的Bug之外，很多Bug都是开发、测试、策划、项目经理共责的，为了团队的团结，也没有必要去讨论哪个团队负主要责任。
3、Bug影响范围，分析这个Bug对于用户造成的影响。
4、改进措施，在改进措施这一项中，可以把以后如何避免类似Bug的措施写进去，并在任务系统建立任务，指定专门的人跟进。
那再来说下项目组实际Bug的责任认定吧：
1、如果测试时间还是比较充足，测试用例有写，但是还是漏测的，那就是测试的责任。
2、如果测试时间不充足，测试用例有写，但是因为时间不足而降低回归测试范围，导致漏测的，那一般是项目组各个角色共责的。
3、如果有开发修改了功能没有通知测试人员，导致线上漏测的，那就是开发的责任。
4、如果策划人员在回归测试阶段还提了需求变更，在测试人员明确告知风险的情况下还坚持要上需求变更的，那就是策划的责任。
具体问题具体分析。
如果是测试同学没有覆盖到的场景，产品同学没有想到的场景，开发同学代码没有cover的场景，那么所有人都有责任。
就我经验来看呢。上线之后出现的问题大部分是：环境问题。
什么配置信息丢了，这个配置信息忘记配了，还有域名冲突等等。
不过，不管遇到什么问题，沟通和流程化的上线规范其实是最最关键的。
但是，很多互联网公司，其实大部分不是这样的。测试背锅侠，好像叫的就是这么顺口。
不过在我待的公司(准确的说应该是我所在的那个测试组)，我们的测试老大很厉害。很多问题都会把情况说明，比如：
1.这个问题产生的情况原因，需要测试同学了解清楚。严重的问题可能会领导们一起开个会，讨论解决办法。
2.环境问题，我的测试领导会主动去推研发同学，制定相关联的流程规范，怎么尽量去避免此类问题发生。
3.不确定性问题，概率问题。会后期进行复现，可能借助的工具除了自动化测试工具。然后如果该问题大面积出现(还是概率问题)，那么会组织相关同学进行解决。
所以，测试同学应该拿出自己的观点和态度。当然，其实最重要的还是你的领导是如何对其他团队说明这件事情的。
我们公司的bug定责是这样一种规范：
出现bug，那么分析bug是不是这次的测试用例没有覆盖到这个点。
1，如果有覆盖到但是没执行，那就是测试背；（这种类型导致的锅比较沉）
2，如果没有覆盖到，那么会分析为什么没有覆盖到，因为在确定测试范围的时候，会把这次的功能和关联的功能一起划定到这个范围内（这个锅就是领导的了，领导请接好）
3，如果范围有覆盖到，但是用例没有覆盖到，那么这个锅就是编写测试用例人员的锅了。（这种类型的锅会轻一些，毕竟人非圣贤孰能无过）；
4，如果有开发改动没有知会测试导致的；（这锅，开发请接好）
写到最后：其实谁的锅不重要，重要的是我们要学会多进行复盘，对已有导致的问题进行分析，总结，之后避免再次触犯，或者减少触犯的几率，这才是我们最终的目标，毕竟开发和测试是相互协作，共同相辅相成的，还是要保持良好的关系，培养每个员工自省的能力，而不是相互推诿，互相甩锅！！！
具体问题具体分析，举几个例子：
1、假设是软件版本更新，开发人员在进行影响分析时漏掉了可能会影响的一个功能，而测试也没有测到这个功能，恰恰这个功能上线出了问题，那没说的，开发的责任；
2、软件开发延期导致原本两轮的测试变为一轮测试，测试不充分导致出现BUG，这应该是整个项目组的责任；
3、软件按时提交测试，BUG出现在测试覆盖范围内，那么就是测试的责任；
4、测试BUG较多，测试部门要求延期上线，结果客户或者领导压下来，说必须按时上线，你说这是谁的问题？