绩效垫底。。。问下广大 v 友，测试发出的程序有问题算开发还是测试的锅？

[loriann]

是这样的，本人在开发过程中有几次出现线上版本出问题，领导警告再这样提桶走人。但是我想不通测试测好的程序出问题为什么要怪在开发头上呢。。。。

[yyttrr]

第一次你大锅测试小锅，后续的你全锅

[lxd152]

@darknoll 不重要的 bug 一堆，那么只能说明你写的代码很 low ，写一行是一行，也不做自测，。负责任的开发是不会写一些明眼就能看出的 bug 。

[wd]

你想想测试的工资和开发的是不是一样多

[yongzhenchen682]

嗯，测试场景都过了吗？就是把测试案例拿出来开会讨论，如果一堆人都没人提出这个问题，测试不主锅。如果有涉及到这个场景，测试没测，测试主锅。这是基于业务的测试。
如果是内存溢出之类的问题，业务测试测不出来，开发代码稀烂之类，还得问问自己或测试是否压测过。

[lxd152]

身为测试~想说几句，仅代表个人。首先 bug 出现，那么肯定就有问题。那么问题是大，还是小。业务逻辑问题，还是代码异常，还是崩溃，还是性能问题等等。标准的产品测试流程：开发单元测试-->冒烟测试（正向主流程业务，开发测，测试提供用例）-->测试进行全面测试---产品验收测试。所以如果标准化，出现 bug ，谁都有锅，只是取决于 bug 大不大，有没有造成损失，到底要不要追责，等等等等。几年的工作经验告诉我：有 bug 就解决，不要第二次发生。bug 是不可能完全没有的，只能尽可能的做到更少的 bug ，更优的代码。都是 team ，大家都好好写，好好干，帮别人也是帮自己。

[leafre]

其实只是领导看你不顺眼，想开你。

如果是测试的职责，如集成、端对端就是测试的锅，单元测试范围是开发的锅

[gologle]

责任的划分，与项目的性质相关，假设如是高并发面向 C 端的产品，则责任可以这样划分。

对于开发，
假设上线前，测出的 BUG ，开发须承担的责任为 1 ，
则上线后，出现的 BUG ，开发须承担的责任为 2 。
也就是说，BUG 的产生，开发必然有责任，若在测试阶段就发现，则责任小一些，拖到上线再发现，责任翻倍。

对于测试，上线前测出的 BUG ，测试须承担的责任为 0 ，即无须承担责任，
而上线后，出现的 BUG ，须承担的责任是 2 ，即与开发负同等双倍责任。

[linglongll]

点工没点全呗 如果出现的问题不出现在测试用例中的话 那就说明出的测试用例不全啊 不全的话谁的锅不用说了吧 公司都是各司其职的 开发的任务就是开发 测试的任务就是测试 不用去管极端的例子 出了问题俩人都得担责 但是从职责角度看确实是用例覆盖不够广泛 或者你们可以一起骂产品出的东西逻辑复杂了 众所周知 如果写一行打印 hello world 的话是不会出问题的 只能说老哥你的 leader 做的有点不妥 但是想想 你出问题了 你的 leader 是不是也不大好过呀 他不爽了你还想爽是不是不大可能呀

[FranzKafka95]

源头在开发，你是头，测试来把关，把关没把好也有问题。当然，你们领导问题最大，他为什么不考虑从流程体系上去减少这种个人的错误，降低这种失误流出的概率。

[UIXX]

是什么 bug 不说，很难对整件事进行评估。我倾向于具体案例具体分析。

[xumng123]

我所在的大公司，一次性干得好的不如经过很多次攻关的绩效好，多次攻关可以给领导一种这个事情难度很大的错觉。多经历几次后，大家都有样学样儿，简单的事情复杂化都是常态了。

[Akiya]

我觉得 V 站水平还有待提高，视野不要局限在甩锅给谁好吗？
我的建议是把具体的问题贴出来这样更好讨论。

很有可能是流程导致的问题，比如说：
- 代码没有充分 Review
- 没有自测就提给测试
- 测试的测试用例设计没有评审

以上都是可以规范流程解决的。当然你一定要依赖于员工自身的能力也不是不行，那就请提高面试官的水平和薪资，能准确判断出靠谱的工程师，公司的产品出了线上问题当然是公司负责，怎么轮得到一个打工的背锅。如果开发的功能除了问题就要离职，那请问是不是这个功能产生的收益是不是全归你啊？

[xumng123]

具体到开发和测试外泄的这个问题，通常我司的做法是：
1. 开发先上，将错误以冠以临时解决方案堵住—发补丁；
2. 开复盘会议，会议上开发测试互相 pk 甩锅，直到僵持不下，然后领导各打五十大板。第一次复盘失败；
3. 开发测试回去各写整改报告，开发强调后续加强提高覆盖测试用例，测试强调后续加强测试方法与用例覆盖。
4. 第二次复盘会议，开发汇报并给出提高测试覆盖的目标，测试汇报给出测试方法改进与提高测试覆盖的目标。会议圆满结束。
5. 一段时间后，第三次会议，汇报目标完成情况。
6. 经过若干个月，再次出现故障外泄，重复以上动作。
…
7. 价值需求交付越来越少，为了保持需求交付效率，需求拆的越来越小，部门人数越来越多，团队越来越多，各个角色就越来越多，会议越来越多…

[4771314]

锅要分清
如果是测试没有覆盖到，那测试也是有问题的
如果是测试环境没有问题，上线后出现问题，研发问题大一些，但是测试也是有问题的
总之就是，版本线上问题，所有环节的人一个都跑不掉，这是铁定的，就看老板怎么想了

我们一般都会复盘，基本是大家都分一点责任，不会集中到一个人身上，毕竟是一个团队，这样所有的锅都给一个人，是在是有点说不过去
一个正常的版本，产品提需求->需求评审->UX->UX 评审->开发->提测->上线->回归，大家都在流程里，如果出了问题，不能全怪开发（除非这些环节都是开发一个人负责），上线奖励大家都有，出了问题开发一个人背锅，这是不合理的
之前也遇到过，创业公司，小团队，4 、5 个人，有段时间，需求很赶，上线出问题的次数有点多，leader 的理解就是全部都是开发的问题，经过几次的辩论（撕逼），才有了比较合理的复盘和责任认定机制。
对小团队而言，最容易出现，一出问题，研发祭天的情况，需要时间和经验。