软件上线后出现了重大bug，软件测试工程师负和开发人员谁负主要责任？
背锅其实也就是指生产问题的追责，现在一般的公司都追求敏捷测试，小步快跑，更新迭代速度快，这也就引发了许多的质量问题，一旦这些质量问题在生产中暴露出来，轻则用户体验差，重则造成经济损失。
一、那么锅应该由谁来背？
我觉得发现生产问题要深究产生问题的原因，优先解决问题，将损失降到最低，其次再来考虑事故是由于什么环节导致的，是测试范围预估不正确，导致未测试，还是在范围内漏测，还是开发编写代码导致新问题的产生，我觉得只要在这个团队就都有责任，不能说是单独拎出来某一个人来背锅，其实经理和负责人已经扛了大部分的锅，不会说让某个人来负责、背锅，到团队层面复盘、反思经验教训，大家共同提高进步，我觉得这才是这件事能产生的最有益的价值。
二、如何避免锅从天降？
说到如何避免锅从天降，还不如说如何减少生产问题，提高测试的质量，产品的质量提升了，锅自然也就没了，这样既有利于团队的发展，更有利于对测试质量的提升，我总结了一下几点建议：
1、需求评审
需求评审是关键的一步，提前了解需求，将有异议的地方列举出来在需求评审时提出问题，是业务、开发、测试对于需求的理解保持一致行，能避免后期很多不必要的麻烦。
2、用例评审
用例评审时需要开发和业务人员确认测试点和测试范围，防止用例设计的遗漏。
3、交叉测试
关于其他的一些测试方法测试策略在这里我就不详细说了，但是在我来看交叉测试的测试策略是不可忽略的。
4、暴露问题
可能在测试封版的时候还会遗留一些修复优先级程度低的缺陷，这时有可能会带着这些问题上线，那么就要提前做好与业务和开发人员的沟通，几方沟通确认结果写在测试报告中，是无需修复还是下个版本优化，明确确认人员。
5、风险评估
指的是对本次即将要上线的产品做一个风险的评审和预估，常常伴随着“政治性”的话语，例如对所有浏览器或者手机机型未进行兼容性测试等等类似的话语。
三、如何摆正心态？
若真是自己的问题就要静下心来，反思与总结这次的教训，若是他人的问题也不要一味的抱怨、指责，团队通力合作才是最重要的，我很庆幸我现在是这个团队中的一分子。
