V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
iovekkk
V2EX  ›  程序员

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

  •  
  •   iovekkk · 2022-01-05 14:58:24 +08:00 · 3670 次点击
    这是一个创建于 1085 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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




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


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



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

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

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

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

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

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

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

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

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

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

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

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

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