在近几年的工作中,都是在做测试,把控软件产品。当然,在测试工作中,不可能没有出现 bug。但是在工作中没有出现过很大很严重的 bug。当线上出现一些小问题时,如由于网络原因,H5 页面加载不出来。或者出现偶现的 3 级 bug。你们的领导是怎么对待测试人员的呢?
虽然我的领导不扣钱不扣绩效,但是说话的风格让人很不爽。他接到大领导的反馈后,就是说 app 的 h5 页面加载不出来,他问题都没有考虑是什么原因,就直接在公司同事面前说:你们测试是怎么测的?我勒个去,这让我们如何回答?
还有就是在项目测试过程中,他几乎都会问,测的怎么样了?这句话我就说,下班后我给你发测试进度报告。测的怎么样了这句话,让我真能的很难回答啊。
讲下你们在工作中,遇到我这样的情况时,是怎么处理的呢?
测的怎么样了
天下领导都一样吗
分析 bug 原因,不能老是背锅
问了开发人员,答:马上转测。 扭头就问我:测得怎么样了。 我:????????
现在公司可能是因为本来就不重视测试吧,线上出问题,直接找开发
线上 BUG 说下我现在公司的处理方法:
1、关于线上 BUG 问题,目前公司有一整套线上故障流程规范,包括故障定义、定级、处理流程、故障处理超时升级机制、故障处理小组、故障处罚(与故障存在时长有关)等;
2、最主要的是,线上故障是研发和测试团队的 KPI,KPI 计算是分开的,线上只要出现 BUG,研发必须承担责任;对于测试来说,是复盘的时候确认是不是漏测,只有漏测才会计算测试责任;
3、最重要的是,公司从上下都重视这套故障流程规范,所以应该先建立规范;并让大家都认可,这样研发在开发的时候才会尽心尽力,测试也有更多时间做测试的事;
4、线上 BUG 不可怕,可怕的是没有一份标准来定义责任方;
5、线上 BUG 复盘后的改进方法才是重点;
关于测试过程进度:
1、每份需求都需要需求评审通过,研发方案需要技术评审通过;
2、需求和技术评审通过后,才会进入迭代排期,测试才会出测试计划方案,精确至小时;
最主要的是:
开发出研发协作平台:
1、展示迭代研发过程进度和数据;
2、风险及时推送给 leader;
3、leader 可以随时去查看当前任务及进度;
线上 BUG 谁都遇到过,一次还能原谅,出现两次同样的 BUG 就不太好了。
出现没测到的 BUG 时要去反思为什么没有测到,下次测试的时候就能避免同样的情况。对于一些业务无关的 BUG,比如异常、用户体验相关的,或是特别奇葩的,可以整理到用例库,分享给其他项目组,避免踩同样的坑。
对于你说的因为网络不好 H5 加载不出来,这种问题其实在需求阶段就应该提出来,让 PM 给相应的处理方案,而且在验收报告里面,也应该有相关的风险说明。
其实平时碰到的大多数测试背锅的情况,还真就是测试的原因,测试作为项目流程的最后一道关卡,一定要做好。
测试的怎么样?我觉得这个问法很正常,你得反馈你目前的测试进度,大概什么时候测试完成,中间遇到什么问题,这个问题会不会影响测试进度,你也可以把你写的测试用例反馈给领导,作为一份过程数据,领导也看的到
领导一般这么问,就是因为没有一份过程数据告诉他,他这边需要知道你这边的进度情况
上线,祝你们没有 bug
作为测试老大,我是会偶尔问测得怎么样了。但是我不会经常问,通常是在测试周期进度到二分之一的时候再问。其实问这个就是想了解当前的测试情况、整体产品的质量等等。我通常会在冒烟测试阶段问。真正冒烟测试通过后在测试用例执行阶段我依靠工具就能看到很多数据信息了。很少会问。