nice2cu

讨论:已经被测试人员验收的功能,出了生产 bug,只让开发背锅是不是不公平

  •  
  •   nice2cu · Aug 29, 2024 · 5819 views
    This topic created in 798 days ago, the information mentioned may be changed or developed.
    如果是这样的话,谁还愿意积极去处理这种紧急 bug 问题,还扣绩效。
    36 replies  •  2024-09-03 16:38:38 +08:00
    aiwoshishen
    aiwoshishen
    Aug 29, 2024 via iPhone
    1
    一人一半
    minmini
    minmini
    Aug 29, 2024
    2
    一人一半合适
    arcaitan
    arcaitan
    Aug 29, 2024❤️2
    3
    在菊司, 测试要承担更多责任, 所以测试和开发天天撕逼.
    如果你让测试承担更多责任的时候, 你就会发现你的产品想通过测试变得很难
    andforce
    andforce
    Aug 29, 2024❤️14
    4
    这题我会,主要看这个 bug 是否在测试 case 里,如果测试 case 有就是测试背锅。

    如果没在测试 case 里,就撕为什么不在测试 case 了
    lujianwen9
    lujianwen9
    Aug 29, 2024
    5
    看测试用例,看有没有覆盖这个流程,没有测试担责,有的话一人一半
    15855pm
    15855pm
    Aug 29, 2024❤️1
    6
    很多开发连 20%都不想承担,他们觉得测试应该承担生产阶段 100%的责任。其实漏测的原因可太多了,要具体问题复盘总结,再确定责任比较好。
    tf2
    tf2
    Aug 29, 2024
    7
    我觉得是看情况。

    甚至有一种情况是,需求一开始就歪了,不合理,极易出现 bug 。这种靠开发主观发挥、测试擦屁股才能减少 bug 的,应该 100% 锅给产品经理。
    andforce
    andforce
    Aug 29, 2024
    8
    @lambdaq #7 需求评估就是干这个的,就是说破天线上 bug 也不会是产品背锅~
    lebcvu
    lebcvu
    Aug 29, 2024❤️2
    9
    @andforce 这样也有问题,会导致测试写用例的时候,为了不背锅,细致到一个小功能都能写几十条用例。之前见过一个普通的课程管理后台 7k+条用例的,开发执行通过一定比例才能提测,不然就直接打回。唉,就是玩儿
    jydeng
    jydeng
    Aug 29, 2024
    10
    开发起码同责起步🐶
    jayjoe
    jayjoe
    Aug 29, 2024
    11
    就像#3 楼说的,如果这次你让测试背锅,那下次测试就会卯足了劲给你提 bug ,其实都是打工的,还是好好沟通为上策,有问题解决问题,当然,如果绩效跟这个强挂钩,那每次合作注定大家都难受
    andforce
    andforce
    Aug 29, 2024
    12
    @teslayun #9 这都是知识啊
    wdold
    wdold
    Aug 29, 2024
    13
    一人一半吧,这个没啥扯的
    whosesmile
    whosesmile
    Aug 29, 2024
    14
    除非你自行优化代码,并且没有通知测试人员进行关联测试,其他情况不会让你一个担责。
    Emiya1208
    Emiya1208
    Aug 29, 2024
    15
    我觉得我作为运维背锅比较好(开玩笑,看到 bug 当然先去开喷
    pushMeUp
    pushMeUp
    Aug 29, 2024
    16
    各打五十大板
    Leviathann
    Leviathann
    Aug 29, 2024
    17
    产品无责是吧
    MENGKE
    MENGKE
    Aug 29, 2024
    18
    @lujianwen9 测试都覆盖到了没测出来还让开发担责?
    hero1874
    hero1874
    Aug 29, 2024
    19
    产品呢,有时候产品都搞不明白。。。 然后就歪掉了。。
    bzw875
    bzw875
    Aug 29, 2024
    20
    我之前的甲方,测试和开发一起背锅
    wisetc
    wisetc
    Aug 29, 2024 via iPhone
    21
    背啥锅啊,不背,出生产 bug 咋滴啦,严重吗。既然有严重性,为何当初这么轻易,是诱人犯罪吗。产品所有者是怎么设计的,搞那么复杂,是不是水平差?预料不到是因为创新是吗,创新还是有风险地。可见 QA 一般,这是工作方法问题,当初考虑清楚了没有?把所有工作推给做实际工作的人,是吗,这是他能够考虑到的吗
    so2back
    so2back
    Aug 29, 2024
    22
    我这边产品特么的设计完就不管了,关键设计的不怎样,还从来不验收,一有问题就狗叫开发当初怎么做成这样,每次都得在群里怼产品
    iyaozhen
    iyaozhen
    Aug 29, 2024
    23
    我是 QA
    这个要具体问题具体分析,但就我们项目现在来说,即使研发自测的项目出问题了,QA 也得负责

    另外还有一些红线,比如研发夹带私货、上线操作不规范等
    sumu
    sumu
    Aug 29, 2024❤️1
    24
    测试?有测试就偷笑吧
    很多大厂在两三年前就开始裁撤测试,由开发保障质量,有一套所谓的质量左移理论,出了故障根本没得甩
    tf2
    tf2
    Aug 30, 2024
    25
    @andforce 理论上需求评估是干这个的,但是码农有否决权吗?说破天,就是领导想要这么干。
    andforce
    andforce
    Aug 30, 2024
    26
    @lambdaq #25 那就让老板背锅
    yagamil
    yagamil
    Aug 30, 2024
    27
    主要还要看是什么类型的 bug ,不能一刀切。

    要是功能性的问题,必现的,这种漏测就说不过去了。

    要是 conrner case ,比如用户关联 N 个操作,同时在线人数大于几十万,实际应用场景造成的 bug ,我觉得这个生产上很正常,尤其第一款产品在产品初期。 你也想不到有些用户会这么个操作法。

    慢慢完善就好了。 都是打工的,没必要上升的大格局
    joker622
    joker622
    Aug 30, 2024
    28
    测试,天天背锅走售后,每天在挨叼和被叼之间来回横跳
    bengcaca
    bengcaca
    Aug 31, 2024
    29
    只要是生产环境,责任分派一般的是测试( 50%)、开发( 30%)、产品( 20%)。
    具体情况具体分析,在这个标准基础上浮动。

    如果主要是设计问题,那 pm 就要承担更多责任;
    如果主要是执行问题,那 rd 就要承担更多责任;
    无论如何,只要是线上,测试的责任一般不少于 50%。

    以上只是在出现比较严重问题的情况下,需要复盘时才会按照这个流程走。如果只是普通问题,也不会闲的蛋疼去折腾这个,定责的时候才是体现人性的时候,这种流程走多了,公司氛围基本就要垮了。
    qooweds
    qooweds
    Sep 1, 2024
    30
    现在测试都快被裁光了, 要是开发测试比要是大于 10:1 就别扯测试背锅的事了
    nicklooo
    nicklooo
    Sep 1, 2024
    31
    开发经理、测试经理背锅
    haoswil
    haoswil
    Sep 2, 2024
    32
    说话语权重谁担主责
    me1onsoda
    me1onsoda
    Sep 2, 2024
    33
    @lambdaq #7 前提是事前说了或者评估的时候把风险提前暴露。事后搁那巴拉巴拉就有甩锅嫌疑
    Adia
    Adia
    Sep 2, 2024
    34
    据我所知,有一部分厂子是 55 开
    nonempty
    nonempty
    Sep 2, 2024
    35
    这个锅就该领导背大头
    a7851578
    a7851578
    Sep 3, 2024
    36
    这里的问题不是要追究的谁的责任,而是复盘为啥被漏了,下次尽量避免场景补上。如果追究责任,一般大公司是公司赔钱不会落到具体的人身上,除非是某个具体的对接人出的问题例如发版操作的运维没有灰度。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   1348 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 79ms · UTC 19:40 · PVG 03:40 · LAX 11:40 · JFK 14:40
    ♥ Do have faith in what you're doing.