由于现在的互联网公司对于线上问题的出现，会对责任人进行追责，并按照事故等级进行相应的处罚。
而且这种所谓的处罚会跟绩效或者money挂钩，因此在出现上问题的时候原本“和谐”的项目组各个位置的成员会使出浑身解数相互甩锅。
一般情况下，某些公司中作为项目上线前的最后一道防线的QA同学，首当其冲理所当然就成了“背锅侠”的首选人员。
“QA流程没测全” ”QA用例覆盖不够全面“ ”我代码没问题“ ”需求没改呀“ 随着洪水般叽叽喳喳的”训责“声从腹腔里喷薄而出。
QA同学们大多情况下是百口莫辩，作为团队里”最没有发言权“”最不受重视“ 但是 “本质很重要” 的一类群体，尽管有万种委屈，”这个bug应为时间紧采取紧急策略，理论上并不会影响覆盖率“ “研发人员给与只测试某某某功能的基本流程，点下就行啦，肯定没事的啦，我着急打包提交集成” ”与自身不相关的模块本身应该由专人负责，上线后也在之前收到通知“。。。。。。。
亲身经历，由于产品配置的策略，导致的线上bug，具体问题的过程出现如下：
由于之前未解决某某线上问题Q1，PM同学使用S1系统上线了一个线上策略P1，当时美美哒的解决了线上的问题A。但是这个策略后续对某产品模块M1产生了影响（这是后话，提前说明一下），但是，但是，这个策略上线时QA同学并不知情。因此后续也并未将该策略考虑在测试范畴之内，这便埋下了隐患。
后期QA同学按照正常的测试策略以及测试CASE去测试该产品模块很长一段时间均为发现问题（因为策略为触发，也发现不了），从此以为过上了没有线上问题的没羞没臊的职业生活。
就在此时，一个业务流程极其不规范的紧急需求打破了QA同学本该享受的宁静生活，该紧急需求的”生涯“具体如下：
- 突然有一天，在一个阳光不怎么明媚温暖的下午纷纷扰扰的进行需求的测试中，可爱的微信一闪，研发同学礼貌的打了个招呼，”嘿，老哥，这边有个紧急的需求，验一下子呀？今天下班前的提交集成“ ”什么背景？“ ”就是之前呢个xxxxxxxxxx, 就看在出不出现这个问题就行“，到这里PM同学并不知晓这个需求
- 经过上面一段沁人心脾的对话之后，QA同学并未对研发同学轻松验证的提议打动，而是针对性的思考，由于是兼容问题报的错误，结合时间的紧迫性（下班前集成），对问题的流程进行多个终端的兼容性验证。
- 在马不停蹄的紧急支援一下午，QA同学开心的将没有发现问题的模块紧急提交集成
- 由于修改了东西，这里研发同学升级了模块的版本号（问题触发根源）
- 上线之前未通知QA进行再次验证，这里一般QA同学会走基本流程。
- 上线之后变出了线上问题，但是问题于接近一天的时间后报出
各位看官看到这里，心中有自己的想法，我们不必纠结。
但是不知道给为QA同学是否有过背锅的经历，只想结合这个事件，告诉世界：
我们不背锅！
- 以后紧急支援的需求，你也给我只会产品，走完成的流程，否则爱谁侧是谁测试！
我们不背锅！
- 以后这种可以跟我讲有多紧急，但是少刮点妖风，腰细站不住。
我们不背锅！
- 无论任何测试中，监控系统暴露的问题，全都赐予bug的光荣称号荣登巴格斯榜单!
我们不背锅！
- 不管是大版本还是小版本重要的流程还是都过一下吧，记住多要时间。这种上线前不通知的，需要记录一下让相关人员上线前及时反馈情况！
我们不背锅！
- PM同学以后搞事情的事，叫上QA同学一起玩耍呀！
我们不背锅！
- 相关的项目沟通其他负责的QA功能将两个业务相关部分覆盖到
replay到此结束，以上观点非针对任何角色，纯属娱乐。如果有更好的不被动背锅技巧，请不吝交流。
每一个项目成员都很辛苦，感谢大家的优秀，加油！
老铁们，共同学习。see you!
作者info
一个low的有态度的不是开发但喜欢技术的QA