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

[iovekkk]

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

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

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

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

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

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

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

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

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

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

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

[iyaozhen]

多年 QA 老油条

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

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

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

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

建议就是先把 bug 按一定标准分级，要看实际影响，比如有些偶现的，但出现了影响非常大，就提高 bug 优先级。我觉得时间那么赶，P0 的都不一定修的完

[kieoo]

我认为测试无法复现,可以记录, 但不能记录为 bug;
无法复现的问题数量: QA 的能力问题
bug 的数量: RD 的能力问题
至于工期赶, 那就 RD QA 坐到一起结对开发测试吧, 效率会高些, 冲突也小些

[MsHan]

对我们测试也很无语，版本烂成那样都能过。
用例我看过，按照描述的步骤都执行不下去，无语。

[msg7086]

问题超纲了，我们这边都有自动化测试，不怎么需要测试人员。出问题都是程序员的锅，测试没写好。

[IvanLi127]

QA 要尽力复现，或者说可以让开发帮忙复现，但是没能复现是 QA 的锅，估计也算不了 BUG 了。正常测试要有用例，测到这步前，操作都比较确定，重置环境再测到这步一般也能复现呐

[hanswu]

emmm, 就我自己而言 ， 每次测试出现偶现 bug 的话， 如果在测试三遍以上后，不能复现但是当时已经抓到 log 的话，会提出一个优先级低的 bug 单，并且会跟开发那边沟通 。如果有时间的话就会再次尝试复现，项目时间紧的话这个 bug 会一直被拖到下个版本再去碰，超过三个版本没有再次复现的话，这个 bug 就会被关闭。
主要是 我们公司对偶现 bug 定级也比较低 ，只有客户投诉的时候才要求去一直复现

[comoyi]

压缩开发 /测试时间就要接受一定的出 BUG 的风险，这是话事人作出的选择（妥协）

[toast]

测试报过来，我看完能猜出大概原因的直接处理，猜不出我也复现不了的请 QA 同学继续复现；
相互体谅~

[dundun1]

科学的开发团队，把开发跟测试合二为一。这样就没办法甩锅了。

只要是开发跟测试分开，这种问题永远避免不了。

[751327]

客户反馈的问题都是直接反馈给开发的，因为反馈给测试，测试大概率复现不了也解决不了
如果是影响比较大的 bug ，责任都是开发承担，说实话，我不知道我们公司的测试有什么用

[751327]

或者说就不应该有测试这个职位

[wsseo]

我朋友公司的测试就是打杂的，测试新版本跟开发周旋，敦促开发人员，需求文档不清楚给开发提建议，处理客户反馈问题，跟踪解决，端茶送水，装系统修电脑。