我们根据问题的严重程度影响绩效，开发测试都背锅

有些奇怪的 bug 真的没法~

不是严重的一般都没追责，解决就好。总是修修补补嘛，哪有那么完美的。

雷没探出来，探雷的责任，埋雷的没事！不懂软件工程的都是这样管理的

雷也有哑炮的时候，但是过一段时间就炸了

我一直觉得是测试的问题。但我们这里出了重大问题，基本都是研发背锅，哪怕是测试稍微细心一点，用例覆盖的全一点，就能找出的 bug 的情况，也归属研发的责任。

殊不知，质量不是测出来的，而是生产出来的呀！

这句话虽然有道理，但真出事故了不能这么说。一旦这么说，领导下一句就是：那我请你们测试干嘛？

核心还是看问题的复杂度，如果是那种特别明显一用就发现的（比如一启动就闪退），该反思的就反思，该负责任就负责任。如果确实是很复杂，甚至是测试环境没法复现，线上才会有的，那就做好复盘，预防下一次。至少我待过的公司，出问题后的处理关注重点是问题的解决、复盘和预防，而不是追责。过度追责非常容易导致 “做多错多，干脆不做”。

还是得看公司，看问题是不是很明显就是漏测导致的，很多小公司不管什么问题都归结于漏测，毕竟在这个大环境下，测试背锅是常态，甚至有些公司的测试人员背锅已经到麻木状态，这种情况下漏测概率很大。所谓的流程规范在小公司被很多人拿来当挡箭牌，不发挥实际作用。

作为一个测试人员，线上出问题不是本来就应该第一时间想到为什么没测到？
研发写出来就没问题老板还花钱养测试做什么，抛开追责的问题不谈，作为一个测试自我反省不是应该的吗
研发测试都有锅，简单的流程问题测试更是大锅

一般罚款，根据大小，罚款，记过，记大过，绩效 0 ，开除

认可。我认为优秀的测试需要有高度的责任心。

质量共建

罚谁，测试 or 开发，还是都罚

高度的责任心，必须享有同等的待遇

罚款？ 赶紧跑路吧

对于这个场景太熟悉不过了，在大公司也算是常见了，深有体会。
1、外网出现了 BUG，第一反应不是解决问题，是马上拉测试进群，让测试复现。
2、测试复现出来了，开发和产品质问测试之前版本有吗，用上个版本看下，让测试回溯版本。
3、回溯出来确认了 bug，开发质问之前测了吗，为什么之前没有发现。
4、测试承认漏测，开发马上拉 leader 进群，向产品 Leader 汇报，测试之前没跑到。
5、给出结论：因为测试没有跑到，所以这个问题出现了。
6、for 循环回到第一步。
7、总结：测试不行。
那么，谈到解决之道，其实是整个团队或者说整个行业都存在这样的风气，国内功能测试对于过程质量的把控力度太弱，导致在最后外网复盘环节，更没有话语权了，因为国内产品对于质量目标的认同，却不对过程目标的认同，这是最割裂的认知层次和方向不同，这是测试赛道的悲哀。

提到共建。我认为最重要的一点是共识，没有共识，谈什么共建呢，那么共识一定是有共同的目标，有共同的目标前提是有个人的利益。
现在问题来了，共同的利益在哪里？
开发的利益：0bug，根本没有工作量，老板会认为事情非常简单
产品的利益：0bug，那就不能反复折腾了，一门是一门
测试的利益：0bug，那测试可以很本分交付一个高质量产品
可见，当你去细分这个利益时候，发现这张饼显然并不是利益共同体，反而让开发和产品承担了下游风险。所以，共识很难形成，就算形成，也很难落地，所以你提到的共建，其实很难。

死道友不要死贫道，人之常情，特别是大龄团队，背锅=影响收入=可能失业=一家人没饭吃，非常焦虑。但是如果开发和产品的工作靠 bug 来导向，那肯定是团队出了问题，考核和指标的设置也可能已经变质，一个团队共同利益都没，就是外包的个体，确实谈不上共建，不内卷已经不错了。

没太理解这位朋友为啥会这么考虑呢？不管是对开发还是对产品，出 bug 对他们利益都不能算是正向利益吧？

开发的核心利益应该是通过完成功能的开发，交付系统给业务产生价值
产品的核心利益应该是通过设计具体产品细节体验，通过交付出去的良好产品产生业务价值

出了 bug，开发的交付会出现延期，产品的体验也会打折扣，这两个都会影响他们的核心利益，少一些 bug 对他们应该是利大于弊的。所以没明白为何你上面的推理为什么会显得好像没有 bug 后，开发、产品价值就受到很大影响？

如果你经历过 2 个以上的大型公司，大型团队就知道了。你提到了开发和产品，怎么没考虑到测试的核心利益是什么呢？是 1 个 Bug 都没有吗，那我需要测试团队做什么呢？另外，你提到的开发和产品的观点很理想情况，实际上开发并不认为 0bug 是他的核心，他的核心是在加班比较少情况下更快结单，更快转给测试。产品的目标是尽快转给测试提 bug 修复或者 bug 转需求做。这是大型团队的现状。

是的 大型团队里面，死道友的情况太常见了，出了问题第一个甩锅让测试找原因，不会找自身的原因

额，我没提到 0 bug 是开发的核心呀，不知道为啥你会说这个。我想表达的是开发和产品的核心都和 0 bug 关系不大，0 bug 不会是大家的共同目标。

你提到的这种缺失也确实可能存在，但我觉得这不是一个健康的状态。不尝试去改变兄弟团队这种心态，测试只会越来越累，一直背锅。