V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
iovekkk
V2EX  ›  程序员

讨论一下测试人员的工作职责问题

  •  
  •   iovekkk · 135 天前 · 2612 次点击
    这是一个创建于 135 天前的主题,其中的信息可能已经有所发展或是发生改变。

    有没有测试岗位的朋友,想讨论一个问题

    问题起因是前段时间,公司项目由于前期问题太多,压缩了后面的测试周期

    这就导致了开发与测试身上都肩负着比较大的压力,开发要尽量解决所有的 bug ,测试要尽量找出所有的 bug ,让项目质量在短时间内趋于稳定

    然后开发与测试之间就出现了一个不小的矛盾,那就是:测试提的偶现 bug 数量太多了

    然后这些所谓的偶现 bug 实际上大部分都是有规律的可复现 bug ,在一定条件下必现

    现在的矛盾就是,测试在测试过程中,偶然发现了一些异常问题之后,立刻就截图导日志,然后简单重试一两次,发现无法复现之后就立刻提了 bug ,然后标记为偶现问题

    然后开发在处理这些缺陷的时候,只能自己反复尝试复现再找出原因去解决,比较耗时间

    如果测试能够准确的提供复现路径的话,开发解决缺陷的速度能够大幅提升。而且其实有比较多的所谓的偶现 bug ,复现路径并不难发现,但是依然被标记为偶现

    那么现在的问题就是,对于这些一定条件下必现的 bug ,测试有没有义务去找出复现路径?

    努力尝试找出复现路径,算不算测试的本职工作?

    该问题仅作讨论,请各位理性分析,感谢。

    32 条回复    2022-01-07 11:56:08 +08:00
    Nevermore1234
        1
    Nevermore1234  
       135 天前
    测试有责任找出复现路径,同时时间不够是 PM 的责任
    5boy
        2
    5boy  
       135 天前
    那还要测试有啥用?
    guyeu
        3
    guyeu  
       135 天前
    这不是测试职责的问题,这是拉垮的项目经理和拉垮的排期的问题
    Leonard
        4
    Leonard  
       135 天前
    单说“找出复现路径这点”肯定是测试的职责。
    2i2Re2PLMaDnghL
        5
    2i2Re2PLMaDnghL  
       135 天前
    这样的测试还不如 sentry
    paradoxs
        6
    paradoxs  
       135 天前
    有专门的测试人员已经很好了

    其实公司完全可以把测试任务压到开发身上,直接 996 ,不愿意干就。。
    coderluan
        7
    coderluan  
       135 天前
    ”那么现在的问题就是,对于这些一定条件下必现的 bug ,测试有没有义务去找出复现路径?“

    毫无意义是由义务的,但是在未为保证对方权利(合理的测试周期)的前提下,指望对方好好的完成义务是不现实的。
    RiceNoodle
        8
    RiceNoodle  
       135 天前   ❤️ 3
    “努力尝试找出复现路径”,在我看来,是开发和测试的共同本职工作。因为有的偶现问题,确实从代码可以分析逻辑,然后手动制造条件复现。

    如果开发很难复现和解决的话,我之前一般是把 bug 转入"挂起"状态,责任人流转给测试。
    测试会在后续的版本中,间隔一段时间把挂起问题尝试复现,如果仍然没法复现就转为关闭。

    把 bug 转入"挂起"的过程,需要和测试同学沟通好,说明开发的确努力找过问题(分析过代码,也尝试过复现),没法复现。如果有争议,可以把问题知会到测试和开发的 leader ,看看是否要花时间继续投入复现解决。


    其时测试的主要工作是保障交付质量,而不是找到并消灭每一个 bug 。
    因此如果特性的偶现 bug 很少,测试对发布版本有信心的话,就可以宽松的允许 bug 转入挂起状态。
    如果特性的偶现 bug 很多,测试对发布版本质量没信心的话,则可以据理力争,让开发投入更多精力尝试解决偶现 bug 。
    66beta
        9
    66beta  
       135 天前   ❤️ 7
    老板成功把排期矛盾,转移为开发与测试的内部矛盾
    ah64zzpk
        10
    ah64zzpk  
       135 天前
    正常情况下是有这个责任的,但是在版本交付压力非常大的情况下,往往会出现这样的情况,有可能是测试的覆盖并不达标赶进度,或者是测试人员有 bug 数量的考核指标等等,这种情况我建议你找你的老大去和测试的老大谈。
    其次,对于偶现的 bug ,开发需要有能力去分析问题出现的时候发生了什么,这需要详尽合理的错误日志,以及一些其他可以辅助你定位问题的工具,你现在可以要求测试人员帮忙复现 bug ,如果一旦问题在线上被客户发现,你没法去问客户这个问题是不是偶现,必现的规律是什么,定位分析就全靠你自己了。
    c8c
        11
    c8c  
       135 天前   ❤️ 1
    Q: 努力尝试找出复现路径,算不算测试的本职工作?
    A: 当然算了
    lagoon
        12
    lagoon  
       135 天前
    作为开发,我觉得“复现”这事,是共同有责任的。


    至于是不是测试的工作,我觉得是的。
    不过,也是开发的本职工作,毕竟测试已经截图留证,证明代码有 bug 。




    另外很多时候,就是一环压一环。
    比如时间很赶,以前甚至遇到过,那开发甚至直接写个假代码,到时候测试提 bug ,再具体实现。
    然后最终的情况就是,开发一周,测试一个月。


    所以我深刻的觉得,领导,很重要。
    如何平衡这些矛盾,让项目比较好的展开。



    可惜如今的领导,都是官僚,不进行管理,只进行命令。
    我不管你们怎么搞,我就要结果。
    ahsjs
        13
    ahsjs  
       135 天前
    偶现的要开发和测试配合测试所有情况下的,费时间是正常的
    bluexsky
        14
    bluexsky  
       135 天前
    发现无法复现之后就立刻提了 bug ,然后标记为偶现问题

    那这样提出来的 bug 级别较低,开发可以暂时不理会,状态标注为已知,然后开放的精力放在解决优先级高的 bug 上。

    如果是必现的 bug,级别就会开得很高,这时候开发就需要关注了

    开发空闲的时候可以解决优先级低的 bug,这时候如果复现问题很困难,可以把 bug 打回给测试“无法复现”,让测试再去重现问题。
    ctro15547
        15
    ctro15547  
       135 天前
    偶现 bug 一般会标记复现率:1/10 、1/3 、测试过程只出现 1 次,这样,不是一直要试到有绝对路径(因为有些问题确实没有太固定的路径,有可能是网络波动 机器性能 特定的数据被录入后才出现,但数据又不能被重现),这样很浪费测试时间 ,发报告的时候就可以跟大家伙评估下优先级,让产品开发来定延迟解决还是需要立马处理(丢锅),毕竟东西不是自己写出来的 不清楚会牵连到其他功能,报告以后需要开发他们讨论

    测试过程中 有时间的前提下 ,能接触到源码 或者看得到后台数据或者 log ,可以尝试分析下
    liuhuansir
        16
    liuhuansir  
       135 天前
    复现当然是测试的职责,但是在不懂代码的情况下,想要快速复现偶现的问题真的很费时间,测试和开发合作才是最快的,我们组现阶段就是这样
    fangcan
        17
    fangcan  
       135 天前
    说个题外话, 后端跟测试和前端真的是做不了朋友,利益冲突,互相甩锅,双方都想少做点事情
    hideonwhere
        18
    hideonwhere  
       135 天前
    之前在一家公司测试是有专门摄像头记录仪来记录测试操作的,记录仪有时间戳
    然后出现 bug 测试把那一段时间的视频和日志上次到特定地方 管理再判断是那个开发在下发出去
    最终开发收到再去修改
    zhangshine
        19
    zhangshine  
       135 天前
    > 而且其实有比较多的所谓的偶现 bug ,复现路径并不难发现,但是依然被标记为偶现

    开发觉得不难发现并不能说明测试也可以不难发现。开发对整体代码有一定的了解,对于一些 bug 猜都可以猜出来,也算是一些发现 bug 的隐形加成。但是对于测试来说就是黑盒,前后逻辑可能联系不起来。

    我觉得开发和测试之间不必互怼,问题还是在于“公司项目由于前期问题太多,压缩了后面的测试周期”,莫要底层互耗。
    PainAndLove
        20
    PainAndLove  
       135 天前
    哎,都是矛盾转移之后的受害者...
    iyaozhen
        21
    iyaozhen  
       135 天前
    多年 QA 老油条

    测试有没有义务去找出复现路径?
    有,但其实开发也有

    努力尝试找出复现路径,算不算测试的本职工作?
    算,但也是开发的工作

    楼上说的对,就是周期压的太紧了,测试和开发都顶不住了,因为每个人的能力还是有限的。你觉得 QA 提的 bug 垃圾,QA 还觉得你代码写的垃圾呢。

    有些 bug 确实,很可能定位都得 1-3 天,而且需要高工投入。

    建议就是先把 bug 按一定标准分级,要看实际影响,比如有些偶现的,但出现了影响非常大,就提高 bug 优先级。我觉得时间那么赶,P0 的都不一定修的完
    kieoo
        22
    kieoo  
       135 天前
    我认为测试无法复现,可以记录, 但不能记录为 bug;
    无法复现的问题数量: QA 的能力问题
    bug 的数量: RD 的能力问题
    至于工期赶, 那就 RD QA 坐到一起结对开发测试吧, 效率会高些, 冲突也小些
    MsHan
        23
    MsHan  
       135 天前
    对我们测试也很无语,版本烂成那样都能过。
    用例我看过,按照描述的步骤都执行不下去,无语。
    msg7086
        24
    msg7086  
       134 天前
    问题超纲了,我们这边都有自动化测试,不怎么需要测试人员。出问题都是程序员的锅,测试没写好。
    IvanLi127
        25
    IvanLi127  
       134 天前 via Android
    QA 要尽力复现,或者说可以让开发帮忙复现,但是没能复现是 QA 的锅,估计也算不了 BUG 了。正常测试要有用例,测到这步前,操作都比较确定,重置环境再测到这步一般也能复现呐
    hanswu
        26
    hanswu  
       134 天前
    emmm, 就我自己而言 , 每次测试出现偶现 bug 的话, 如果在测试三遍以上后,不能复现但是当时已经抓到 log 的话,会提出一个优先级低的 bug 单,并且会跟开发那边沟通 。如果有时间的话就会再次尝试复现,项目时间紧的话这个 bug 会一直被拖到下个版本再去碰,超过三个版本没有再次复现的话,这个 bug 就会被关闭。
    主要是 我们公司对偶现 bug 定级也比较低 ,只有客户投诉的时候才要求去一直复现
    comoyi
        27
    comoyi  
       134 天前
    压缩开发 /测试时间就要接受一定的出 BUG 的风险,这是话事人作出的选择(妥协)
    toast
        28
    toast  
       134 天前
    测试报过来,我看完能猜出大概原因的直接处理,猜不出我也复现不了的请 QA 同学继续复现;
    相互体谅~
    dundun1
        29
    dundun1  
       134 天前
    科学的开发团队,把开发跟测试合二为一。这样就没办法甩锅了。

    只要是开发跟测试分开,这种问题永远避免不了。
    751327
        30
    751327  
       134 天前
    客户反馈的问题都是直接反馈给开发的,因为反馈给测试,测试大概率复现不了也解决不了
    如果是影响比较大的 bug ,责任都是开发承担,说实话,我不知道我们公司的测试有什么用
    751327
        31
    751327  
       134 天前
    或者说就不应该有测试这个职位
    wsseo
        32
    wsseo  
       133 天前
    我朋友公司的测试就是打杂的,测试新版本跟开发周旋,敦促开发人员,需求文档不清楚给开发提建议,处理客户反馈问题,跟踪解决,端茶送水,装系统修电脑。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1167 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 19:43 · PVG 03:43 · LAX 12:43 · JFK 15:43
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.