这说明测试毫无话语权

若是这个版本主要上线的内容，有影响，说明回归测试没做好，确实算是测试的问题，甩不掉，若是测试环境没问题，上线后有问题，还甩给你，提刀砍他

背景是这样，发版没有管控，技术 leader 以赶工为由拖延 bug 修复，半成品代码随意上线。扯皮的这个问题测试回归已经发现了，开发也都知道，技术 leader 也知道，结果是他们都搞忘了做这个任务，按照赶工这种节奏上线了，测试认为你开发不提测我就默认你上线没影响，结果出问题了，让测试负主要责任。

他还有个观点，认为开发只有一种情况需要对线上问题负责任：测试提出来了问题，开发觉得不需要改，线上被客户认为是 Bug。言外之意，只要线上有问题只要不是特别刁钻那种，都应该测出来，出问题就是测试责任。

说明你们的质量体系都没有建设起来，没提测的包怎么能上线呢？

你们测试 leader 呢？不能站出来为你说句话嘛？

是不是你们的流程还有问题，未经过测试就上线除非领导拍板，不然出了问题就是一堆扯皮了！

比我现在好，我现在是技术团队都没话语权

可以负责任，但是你要按我说的来，不符合测试流程，不符合测试准出标准不允许上线，如果上了出问题，就别找我哔哔。质量共建都不懂，当什么 leader。

测试负责的情况其实就一种：从测试手上出去的产品出的问题。
当然有几个前提：1.代码在测试结束后未变 2.出现的问题已在测试阶段提出 3.测试结果为质量较差，不建议上线，然后强行带风险发版 4.出现的问题与需求不符

这种情况，如果是我知道开发没改的，我会在发版报告里面写出风险。如果你们的测试 leader 不这么做，估计就是测试完全没地位了。

测试报告有没有写风险？这种让测试背锅的是测试老大还是开发老大，CTO 么？ 直接甩锅 这个时候就是锻炼功力的时候到了，加油，但是别吵架，站在有理的角度去说，要让你背就背把，只是让你负责，没要你付出什么后果就行，没事给领导背个小锅也是可以的，前提是关系还行，关系不行的直接提刀干他，怕锤子，本来就不是你问题 是吧

那就辩论呀，但是测试的确有部分责任。

我是测试 leader， 确实目前没话语权，上不上线，是不是问题，改不改，全技术 leader 说了算，出了问题就让测试背锅。我已经给 cto 提了，后面给测试话语权，写发版意见邮件抄送他，给技术 leader 压力。
而且这事喜欢双标，前端提了安卓忘了做，让前端负责通知到位，开发提测了测试没注意到，让测试改进，真不知道他是对测试什么仇什么怨。又想让测试多做点 QA，又不给测试放权。

我说的都有责任，共同承担，他非得说测试负主要责任，而且在这一点上他不能让步。
其实我觉得都知道的事情，都是成年人了，测试又不是保姆，自己忘了还反过来怪测试。测试能提出来，是优秀，但不应该成为基本要求，更谈不上背责。
之前还提出只要线上出现 P1 问题 直接扣测试绩效。

既然是吐槽贴，再说 2 个搞笑的事。一个是之前把我叫过去说测试没做回归测试，上线有问题，以后要多加强回归，结果问了相关人员才知道，是提 bug 了的，而且是挂在他头上的，结果不知道。二是有个体验问题，我认为不可用仍然是问题，他觉得还好，想让我通过，而且他也已经给 cto 说了没啥问题了，结果无意间在群里被 cto 看到我的测试结论了，就质问他这不是明显不能用嘛。

任何口头的都不行，要发邮件，意见达成一致，扯皮最麻烦

其实说不定还真不是他跟测试有什么仇怨，应该是想快速上线，不过总得有人背锅，视情节，小问题还好，严重了就别背了，应该是开发出生的 CTO，没办法，官大一级压死人

你们这个开发 leader 和你是同级还是你上级？如果同级，那就把这些事情整理下材料，向上说，让 CTO 明确知道这个问题。CTO 愿意配合那还好，如果 CTO 也和技术 leader 一样观点，那你要做好长期作战准备了，要不断灌输保障质量不只是测试的事情，也不只是测试的责任。

至于这个线上问题的责任，事情已经很明确是安卓开发自己忘记去修复了，那就是安卓开发自己的问题，主要责任应该在他。测试、前端最多是次要责任，然后做出上线决策的也是有责任的。这种硬是让测试背锅的风气不能涨。

PS：之前还提出只要线上出现 P1 问题 直接扣测试绩效 ，这个如果损失很严重，其实应该是扣整个技术团队绩效的，当然也包括测试。但只扣测试肯定不合理，很影响士气，而且也显得其他人没责任。

在测试时要按情况来认真！！编写测试报告的，他催你就报风险啊，这就是测试规避风险的一种方式。只要有人催测试催发版或者不想改某些问题，简单，直接报风险点，但要注意一切都要留下可回溯的证据。风险才是规避甩锅的最好方式！

早日换个正常的公司吧

来不来深圳，可以内推

以后版本发布，做个评审吧!

看样子是测试没有评估好这个没修复的 BUG 对线上环境的影响，只是通过建一个 “任务” 去暂时规避这个 bug 带来的影响，这种会影响线上的 BUG，肯定必须要修复好才能上线。哎，只能说你们公司的测试 Leader 话语权太低了，不够强硬。

1.你有能力打通流程，打通以后你的话语权会稍微高一点。
2.混着，耗着，提升自己。
3.多想想问什么会选这家公司，以后怎么避雷。
吐槽不解决问题。

建议换个公司，对牛弹琴太浪费自己的时间了。

这种问题以前提过，没有用，公司要赶工，不上也没办法。最近 cto 看到质量太烂了，叫停新功能开发，开始做半成品代码屏蔽。

问题产生了，那么接下来如何避免呢，我这提供建议参考一下
以后的需求，开发如果发生了结构变动，需要注明：改动的模块，影响范围，还有出现了问题怎么回滚
这些都注明了，首先我们测试知道了，二是相关技术及产品知晓，避免遗漏

都已经提了 bug ,而且挂在开发头上, 你还能和他一起背锅 ?

要是我, 非得把锅死死的扣在他头上, 一点责任都不会承担

这种公司怎么呆，线上 bug 也要看复现率。如果是复现率很低的 bug，也不应该直接归测试责任。现在这种问题责任都只扔给测试了，其他的更不用说

如果测试把的是最后一道关，那确实要承担部分责任，至少上线前没有关注之前提的问题是否被解决了。
如果上线不需要测试点头，那就 PK 到底

这根本就是开发的问题，让测试背锅说明在他们眼里测试的地位太低了，建议换公司

虽然各种流程没有，但是最后发版本正式一点，至少有个大群 or 邮件组来提醒版本发布。 遗留问题直接内部公告…。

没有通知测试，明确测试范围的就是开发的锅，领导态度很重要