这是你以为的内卷
实际的内卷：
面试造火箭，进去拧螺丝；
招饮水机运维，非 985 211 不要，非统招本不要；
所有项目能外包一律外包，美其名曰降低试错成本；
外包一律最低社保公积金，xx 挣钱 xx 花，一分别想带回家；
无效加班不说了，但是架不住有人真加了还加猝死了，留下一地鸡毛；

哈哈哈

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

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

哈哈，的确现在就这样的，测试测完了还有 BUG 就算是测试的问题了，和开发没有关系，感觉整套思路下来大家都面向锅，而不是面向解决问题和发现问题去看了，每个 BUG 都上纲上线。

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

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

大哥我悟了

跟出这个指标的领导讲，你这个模型它还可以完善，千万不要讲是错的不合理的，要秉着打补丁的逻辑，建议应该从以前的 bug 指标里得出我们团队的数据模型，然后拍个脑袋乘个系数。而且 bug 是分严重层度的，还要按等级乘以系数，这样才和实际情况匹配。反正嘛，看到不合理的就配合着绕弯子，绕到大家知难而退，实在玩不起，就准备准备面试吧，玩不起跑总是可以的。

1，开控制台；2，大拆小；3，把开发打一顿每天必须写几个 bug。

我们之前公司要求每个测试一天要找出 5 个 BUG 不然不准下班