现在主要在知乎,地址:https://www.zhihu.com/people/qqrrm 老的文章在:http://blog.csdn.net/pyp

测试人员不会判断问题是前后端怎么办

上一篇 / 下一篇  2020-08-02 20:51:16 / 个人分类:测试



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大概就是这些。


TAG: 缺陷管理

 

评分:0

我来说两句

日历

« 2024-03-22  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 69388
  • 日志数: 47
  • 图片数: 2
  • 文件数: 2
  • 建立时间: 2006-11-24
  • 更新时间: 2023-01-29

RSS订阅

Open Toolbar