职业经验 开发人员代码 bug 多 测试怎么沟通

Tonyzhang1371 · 2021年02月25日 · 最后由 Maple 回复于 2021年02月26日 · 1112 次阅读

面试官问:“如果你负责部分的某个开发人员经常写出低级的 bug,导致你工作量很大,你怎么和开发沟通?”

共收到 15 条回复 时间 点赞

求答复

给出冒烟测试用例,让开发自测过后再提测

这不应该是开发组长的事么。自测流程都能省了。

1.跟上面 ALEX 说的一样,给冒烟用例
2.如果没有区分用例类别,可以把测试设计思维导图发给开发,让他们对照导图来自测基本功能

面试官都喜欢问这些无聊的问题:
1、开除开发,你没权利
2、什么冒烟测试,自测通过后在提测,SQA 的事,就算有这流程,SQA 也拿开发没办法。
所以最后的结果:还是靠自己,有多少 bug 测多少 bug,改不完是开发的事,否则项目延期就是测试的事了。
😀 😀

如果是我的话,会分两种场景看:

场景一:连冒烟都跑不过的
沟通方式:调整下提测方式,改为提测的时候直接到开发座位,开发操作演示冒烟流程(控制在 30-60 分钟内可以操作完,服务端要部署到测试环境中)是 OK 的才算正式提测。如果现场都演示不过的那现场打回,开发修到演示过了再算作提测。

场景二:冒烟能跑过,后续修复 bug 中出问题
沟通方式:提醒开发做好自测,记录缺陷的时候也标记下哪些是修复 bug 引起的。同时也和开发沟通下,看是不是有什么困难导致没法做好自测(比如多项目并行、此场景不知道怎么自测)。直接沟通无效的话就向上级组长汇报,带上修复 bug 引起新增缺陷的数量数据增强说服力。

大公司一般不会出现这样的情况,出现这样的情况的一般是中小型公司,中小型公司大部分在着重开发的"创造",所以沟通基本不管用,开发该不自测还是不会自测,除非能用自测通过率来考核开

不自测或自测很粗糙 ,出现堵塞的问题,直接拒绝测试,需求的流程走通畅了再提单。不会一上来就进行测试,一般随手玩玩 P0 用例先,边玩边跟开发聊聊天
不过遇到真的堵塞问题,一般都会再玩一会 ,一个早上或一个下午,再提出。谢谢您写的 bug 给我摸鱼的机会

  1. 设置准入标准,引导开发自测
  2. 与开发结对编程,或者引入 TDD
  3. 找下根本原因,技术太差 or 态度敷衍,再针对性的来
  4. KPI、绩效引导下

你应该反问他:开发人员还能写出来高级 Bug 吗???
当出现大量低级或阻塞性问题时,也侧面反映了所在项目中转测入口的管控力度小或者根本没有,另一方面就是开发人员的自测没啥效果或者根本没有。你能做的就两方面:
1.如果有强有力的推动,你可以选择加强并制定转测规则,反向推动开发自测工作的进行和保证。
2.如果没有推动力而且还是孤军奋战,那你可以通过提交问题单,以问题单来逼近来督促来获取管理人员的推动

这个公司不值得去。经常犯低级错误,这是人性不是你流程就能解决问题的)。如果你都能决定流程了,你早就不会需要操心这种问题了

陈恒捷 回复

场景二里面有其他情况,我以前合作的开发经常出现。
1、开发主要精力在处置较为麻烦的问题,比如缓存、性能等,解决之后对业务基本逻辑出现主观偏差,觉得 “哎呀真爽啊,完事”,造成低级问题产生。
2、不屈从于垃圾代码,为兼容当前的业务逻辑,花了额外的功夫做优秀的设计或者对遗留代码做了重构,这种情况也很容易出现低级问题。

除了大家说的流程上的处理手段,我觉得还是要试着去理解一下深层次的原因,逻辑简单,CRUD 不犯低级错误的开发也不见得就是多么出色的开发,因为这些人坑一般挖的比较深;经常犯低级错误的人反而也可能是技术比较好、比较上进的人,只是方法未必到位而已。这样跟开发合作,相互知根知底,了解对方容易出错的习惯,效率一定不会差的——测试和开发的合作也是一个相互培养的过程,俗称磨合。

槽神 回复

嗯嗯,认同磨合这个点,每个开发都有自己的特点,只要能做到互补并不一定就是坏事。

不过有一个点可能还是想讨论下,我接触到技术比较好且比较上进的,会以出低级 bug 为耻,所以自测一般会做得更完善,确保不会出低级错误,避免影响优化带来的好印象。优化后容易出错的容易是炫技型的,这种埋得坑可能更深。。。

陈恒捷 回复

上进也分档次,我说的仅限于把代码搞漂亮点,也并不是炫技,至少不通过加 if else 来实现新的业务逻辑也是一种上进的表现,至于觉悟能不能更进一步,自测通过再提测,这就要再提点提点或者通过流程来帮着提升了……我本人还停留在前一种,虽不耻于堆代码屎山,但是自测这一点上的确不值得骄傲……经常被测试妹子耳提面命😂

如果有绩效考核,那么请加入开发提测不通过率
如果没有,需要测试组长和他们组长在流程上沟通,加入冒烟测试

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册