从根本讲是公司流程方面的问题，和测试人员关系不算太大。

测试人员的主要工作内容是发现缺陷，只要测试人员根据需求写全测试用例，测试过程中执行了全部测试用例，提交的缺陷记录清晰明了没有问题，也很少遗漏缺陷，那么就可以说是一个基本合格的测试人员。

缺陷记录的一个属性项就是发现缺陷的模块，测试人员有义务和责任，表明此条缺陷记录发现在哪个模块，如何发生，但是提交的内容是否正确，测试人员本身其实很多时候是很难确定的。

比如题目中说的一个缺陷是前端问题还是后端问题，在知乎我看到很多开发人员吐槽这件事情了，但是这件事情真的和测试人员关系不算太大，你们是开发人员，一眼能看出来一个缺陷大概发生在哪里，因为什么原因发生的，是否应该由自己还是别人负责，但是测试人员不知道啊。

对于测试人员来说，仅仅是根据测试用例执行，软件预期结果和实际结果不一致，所以发现了一个缺陷，我按照职责记录了下来，至于问题发生真实原因是什么，谁负责处理，who care。当然了，优秀的负责的测试人员会关心相关的问题，会去看源码定位问题，把应该改哪个文件哪行代码都给开发人员标识出来，开发人员只要按照测试人员的记录，直接就把缺陷处理掉了。但是，第一，测试人员的工作也是很繁忙的，不一定有时间帮你们定位问题；第二很多测试人员就是混口饭吃，没有必要把工作做得那么精细；第三很多测试人员的能力也不行，不会定位问题；第四大部分和开发人员的关系也没有到这份上；第五等等等等等。

总之，大部分的测试人员还是只做自己工作责任内的内容，当然了，如果一个公司规定说，测试人员发现的问题测试人员自己处理，我也有自己的开发项目，其实也是自己测试自己维护的。

话题稍微有点远了，我们拉回来看看这件事情应该如何处理。

我开始就说了，这个就是简单的研发流程问题，其实每一个测试人员提交的缺陷，本来就是不应该直接到最终处理问题的人手里面，中间最好有一个确认的过程，这个确认缺陷记录的人，可以是测试Leader，可以是项目经理指定的开发人员，或者由测试人员和指定开发人员协同处理。

缺陷确认需要做以下的内容：

第一：此条缺陷是否是真正的缺陷。比如测试人员理解错误，或者需求变更了等等等，不是缺陷由提交缺陷的测试人员确认后关闭。

第二：此条缺陷是否内容明确。很多测试人员提交的问题，别人看不懂。无法理解的，打回让测试人员补充内容。

第三：此条缺陷是否需要修改。有些问题虽然是缺陷，但是可以不修改，那么经过开发人员和测试人员协商，打上标签，不需要提交給开发人员处理。

第四：此条缺陷处理人员。其实这条就对应了问题，确定缺陷发生的真实模块和处理人员，比如可能一个缺陷表面发生在A模块，但是实际可能B模块的原因，那么把此条缺陷让B模块的开发人员处理。也就顺便确定了前端还是后端等等。

第五：此条缺陷的严重性。严重性从职责讲是由测试人员确定的，但是很多时候严重性可能会和其他的一些什么有的没的东西挂钩，可能会有争议，就需要由更高层次的人协商确认。

第六：此条缺陷的优先级。此条就是由开发人员决定的，就是缺陷的处理顺序。可以由开发leader或者修改缺陷的人决定。

第七：此条缺陷的的类型。这个可以在测试过程完毕后处理，也可以提前处理，就是缺陷真正发生的原因是什么，引入阶段在哪里，就是缺陷类型，缺陷起源，缺陷来源等等。比如是开发人员的需求理解错误，还是就是代码写错了，或者干脆需求就是错误的。在缺陷确认处理的好处是可以查看缺陷聚集情况，查看其他类似地方是否存在类似的问题。

其实大家可以看看我在知乎关于测试方面的回复，基本都归结于各种开发流程而不是具体的人，我个人还是愿意相信大家的职业操守，只要在一个好的合适的适合本单位的开发流程里面，可以尽量的避免个人的因素影响。

大概就是这些。