匿名职言 关于面试大厂软件测试岗的困惑

蒋驰 · 2023年09月05日 · 最后由 叶涛 回复于 2023年09月12日 · 8933 次阅读

楼主面试了某大厂的测试岗,3 轮技术面 +1HR 面,平级面完一面之后过了,找来了上司二面
目前还没收到结果通知,不过估计是挂了
二面磕磕绊绊,其中有一个问题印象深刻
面试官:如果出现了研测双方对需求理解不一致时,该如何解决
回答:
解决:再次认真查看需求文档,根据需求文档内容确定功能的做法,如果我和研发的意见不一致、无法统一,应该找产品确认需求,确认之后要求产品将需求描述清楚
避免:在需求评审阶段加强对需求的理解,有歧义时及时提出、在测试用例评审阶段要求产品和研发一同参与(总之就是从上游就开始减少这种事情发生

面试官:那如果这两个阶段过后还是有歧义呢,找产品确认不是很浪费时间吗?
回答:如果还是出现这种情况,为了减少占用研发时间,我会整理好自己的疑问和解决方案,单方面找产品确认需求,确认之后要求产品将需求描述清楚再告知研发

面试官:研发的时间是时间,测试的就不是了吗?balabala 又抓着这个问题追问了贼久

其实我个人的看法是无法避免走到找产品这一步的,毕竟人微言轻,就算是测试经理那也不能随意确定需求吧,不去找产品确认,那不管是研发还是测试对于需求的理解都有可能是错误的啊😢
想问问各位同行,关于研测双方对需求理解不一致时有什么好办法解决呢

共收到 31 条回复 时间 点赞

找产品确认浪费时间,也比做错误需求,白白做无用功好得多

研测双方对需求理解不一致,是个人都会先找产品确认吧,一锤定音。
我们都是开发、测试、产品拉个群,抛出自己的疑惑,请产品确认,产品自己拿不准的,再进行讨论,最后总能达成一致。这个时间是怎么也节约不出来的。

反问面试官,为啥会出现理解不一致,需求没评审?用例没有评审?设计没有评审?阁下又该如何应对

你不要被他的问题绕进行了,以终为始,需求就应该是明确的,澄清的,如果不清楚就应该理清,BUG 修复的成本在后期可是玩远大于前期,如果遗漏到产品验收时再发现,修改代码,那需求的交付质量将更加难以评估,面试管可能是看你对于有些原则是不是应该坚持,不妥协,这也是测试人员应有的素质

当研测双方对需求理解不一致时,永远是你对,就再也不会出现不一致的情况了。
你——就是可以说话的需求!是产品的代言人!

许立辉 回复

感觉面试官心情不好,急匆匆的被叫过来给我面试,他的态度让我感觉好像研测理解不一致全是我的责任一样,要我必须根治这种问题,我们测试确实需要去跟进和确认,这肯定得有一方做出牺牲去确认的,但不是测试单方面的问题吧,只要是人参与的工作那就一定会有误解,研测产三方都不希望如此,可是无法避免的啊,当时也面很久了比较累,后面发挥得也不太好,确实一直被他带着节奏追问了很久,他也一副非常不满意的样子,很后悔没有反问一句贵公司又是如何处理这类问题的😓

站在面试官的角度,我觉得面试官的这个问题意义不是很大,他想看应聘者处理合作/流程上的 操作和主观能动性,但是这种问题根本区分不出来候选人这方面的能力,所以他会不停的挑刺,看看你的抗压能力和随机应变的能力。这个问题的答案并不重要,因为他的这个问题很 low,99% 的人回答都是千篇一律一样的。所以这个问题就是看你和面试官之间的眼缘。

面试官 核心意思是:我是你领导,不是摆设,你搞不定可以来找我,自己在那里瞎折腾个啥
这是个控制欲很强、对细节很在意的面试官,好坏不便评论,反正不是个吃白饭的就是了

槽神 回复

有这个意思,可能是我在小作坊待惯了吧,提倡独立解决问题,以我狭隘的眼光,我一直以为上司是讨厌你给他制造麻烦的,所以回答的重点一直都在想自己去解决,一时没 get 到他的意思,后面他也有引导我问有没有想过问上级

凡事都有个度,这种沟通上的冲突,独立解决问题在绝大多数团队都不适用,还是要权力对等才能沟通
技术问题肯定是独立解决为上,但是也得有个时限,我以前的要求是半小时没进展必须来找我……要么我来指出方向,要么就是我要跟着你一起研究,不然我哪里知道你最终的结果是不是 “错错得对” 的运气呢~

解决任何问题,如果刚开始的方向不对,后面很可能会花费很多时间才能得到最终方案,高效率团队需要技术性管理,在指引方向和提点思路上必须投入足够的时间,不然就是个路人甲团队,leader 自己晋升吹牛逼都不好吹

王嘉熙 回复

get√ 我道行太浅了还得再练练,一直以来公司管理都是很扁平化的,氛围轻松没啥权力对等才能沟通的说法,但你的回答确实是个有经验的管理者该做出的正确行事风格,能有这样的上司真的很靠谱(呜呜呜,谢谢大佬提醒

蒋驰 回复

解决不了就要向上反馈找 PM 去推动,尤其是在一些跨部门跨团队的需求面前,需求各个部门的开发理解不一致是非常正常的。还有在这种情况下,PO 可能也只是熟悉自己的产品,其他部门的产品可能也不熟悉,需要 PM 去推动更高级别的开发出架构图,方便 PO 理解,再去推动解决这种需求理解问题。比如后续可以组织进行需求反讲

如果我来回答我估计和帖主回答得一模一样,我会觉得面试官纯粹是在找茬……
这种情况我一定会在面试结束的提问环节里反问他会怎么做。

可能这个面试官就是一个硬刚派,或许他想听到的答案就是你直接把问题打回给产品让产品自行细化,不占用研发测试双方的时间。但,这种在现实并不实际,但凡遇到哪怕有一点不配合的产研都无法如此执行,反而只会让测试背上臭名,让人觉得很难配合。

楼上回答 +1。如果是我,我也是第一反应一起找产品确认,产品给的结论实在无法认可,才会找领导出来推。

至于说占用测试时间这个事情,把这个问题当做需求缺陷记录下来,后面复盘的时候用来倒推产品改进就好了,这个时间花得也值,也有助于以后减少这类额外消耗。

不过说实话,这类问题一般沟通得当,不会很占用时间,早会的时候就可以顺带解决了。

楼上回答 +1,个人认为,测试的职责,只是:“发现问题”,但不需要具备:“解决问题”
所以,当你提的 bug,研发觉得不是 bug,尝试跟研发沟通,拿出需求文档,如果沟通无果,丢给产品,让产品去解释,一定不要占用太多时间来跟研发讲需求,你不是:“产品经理”,是:“测试人员”,把自己定位好

你回答的:“如果还是出现这种情况,为了减少占用研发时间,我会整理好自己的疑问和解决方案,单方面找产品确认需求,确认之后要求产品将需求描述清楚再告知研发”,,我觉得是犯了很大一个原则错误,,就是没有认清楚自己是:“测试人员”,为什么需要通过你这个中间人,去给研发传达需求解决方案?就算你讲的很清楚了,研发继续做错,责任还得是你担责,因为是你给研发讲怎么解决,讲什么什么需求,研发就会把锅推给你,你不但还要担责,还浪费自己时间。

如果是我,我会这样回答:

如果是我,我会这样回答,
面试官:如果出现了研测双方对需求理解不一致时,该如何解决
回答:首先,遵循基本原则,以需求文档为准,即以产品为准,如果研发对需求理解不一致,首先找产品确认,先确认自己的需求理解没有问题,如果最后是研发的需求理解错误,那么,让产品去跟研发沟通。

我觉得完全没有必要,再说出,通过什么什么流程避免,通过什么什么手段避免,,这完全是给自己挖坑,因为面试官没问你流程上怎么优化怎么避免,这也不是问题的核心重点,,,所以,才会导致面试官,第二个问题:“那如果这两个阶段过后还是有歧义呢,找产品确认不是很浪费时间吗?”

即使我不说后期可以在需求评审和用例评审阶段多注意该问题,那面试官一样会问第二个问题,甚至还会说总不能每次都这样吧?那我不还是得顺着话题找优化方案
我觉得我的回答和面试官的追问,没有必然的联系,而且给出一个优化方案我认为是很有必要的,面试是双方的博弈,不是全交给面试官,挤牙膏似的问一点答一点,给出合理的答案和优化方案,我不觉得自己回答的模式有太大问题
其它楼层提供的思路也很好,或许面试官想要的不是我们测试去承担这个事,而是希望坚定测试的立场,需求模糊需求有歧义,应该要求产品改进,在需求阶段就占用时间,不应该只由测试承担

蒋驰 回复

😂 只能说,你想太多了。

看你自己怎么理解吧,个人观点是,面试官问什么答什么,除非是自己特别擅长的,你可以这样处理,引导面试官。

你说的,给出优化方案,明显你把面试官引出来了,所以面试官才会问你第二个问题,但是你好像就是在第二个问题跳坑里了,没回答上,明显就是给自己挖坑了。😂

槽神 回复

同意,这个面试官,不好糊弄,而且不管你回答的怎么样,一定会给你挑刺,会不断施压,不过,考察点,应该是侧重于你的反应能力,思考能力,沟通能力,情绪掌握。

面试官的问题只是问如果研发跟测试出现了需求不一致,该如何解决;但是他并未说明是什么阶段出现这个问题,个人看来其实是考察测试 Owner 在不同项目阶段,遇到类似的问题,如何站在不同的角度(当然也得看下这个面试官他是什么角色,他是站在测试的角度去提问还是站在项目的角度上去提问)去做好产品和开发的协调关系。建议回答的时候,可以列举项目在不同项目阶段出现此问题时,你的沟通思路;因为项目处在不同的阶段,处理的缓急程度是有区别的,沟通的代价也是不一样的,对于项目的本身成本也是不一样的

感觉好多人是被 PUA 习惯了么。。。。这么主观的问题纠结这么多分析这么多干啥。。。每个领导的风格都不一样,你面对这个领导的时候他认为做事方法是这样的, 面对另一个领导的时候他认为做事方法是那样的。 还在这分析这么多。。。。你们真是。。。。

孙高飞 回复

理性讨论也没啥吧,问题在我们日常工作中也常见,答案也确实主观 但面试官就非要这样提问,出于压力面也好 真的想考察你也好,就当大家在给职场菜鸟提供了一些其它解题思路咯

孙高飞 回复

那以你的看法,该如何回答第一个问题?

我不知道是哪个大厂,就谈谈我自己的理解吧,我出发点是正向的思考问题,即这个问题是有意义的,也真的真实存在的,不是找茬的,面试官也不是心情不好。
首先要掌握基本情况:
需求:需求文档是不是写的足够清楚,我们是不是足够理解需求内容。
技术:研发侧要实现需求,应该有多种方案,可能不是故意的曲解方案,而是某个方案可能成本最低,风险最小,这时候要从技术角度去理解研发同学的想法,从自己对技术的掌握来判断研发同学说的是不是真的,即使要去和产品对,也能侧面提出论据。
人:研发侧是否有人力来支持方案的实施,人员是否在变动,是否存在请假风险,都很关键,把人的因素考虑进去,综合考虑。
到这里,大概能得出了一些结论,分三种情况:

  1. QA 侧问题:QA 执行者理解需求有误。
  2. RD 侧问题:理解有误,或者方案考虑的不全面。
  3. 需求问题:prd 写的烂,比如一句话需求。 注意问题沟通时候的方式方法,不要只会怼怼怼。 然后要升华到流程,看看是否依靠流程改进,可以根本解决问题(这部分不详细写了,大概意思,要写太也多了): QA 侧:关注 Case 评审的互动、效果、质量 RD 侧:技术评审、技术复盘。 PM 侧:需求质量、粗评、细评。 问题发现环节:哪个阶段发现问题,成本是不同的,要第一时间发现问题。 流程落地 + 监测:调查讨论、文档、实验、宣讲、效果量化、抽检、评估、改进、案例分享学习、推广。

贵司贵小组的规则是什么我就怎么做😂 比如我司产品说了算,研发测试对需求的理解基本躺平,然后就是领导说了算……产品研发测试一起躺平……
挂就挂吧,纠结个啥,真正做事情就做了,扯这些乱七八糟的

吴睿渊 回复

楼主回答的两点就很好了,为什么要怀疑自己,面试官问经过这两个阶段过后还是有歧义呢,找产品确认不是很浪费时间吗?你直接回答:经过这两个阶段就不会有分歧了啊,为什么还会有分歧,如果还有分歧那就三方之间面对面对线,谁赢了谁说了算。而且这种问题纯纯没啥意思,想要你呢你回答啥也感觉很满意,不想要你你回答的再完美也没啥用

孙高飞 回复

我支持你,这种问题你回答的再好,不如面试眼缘好

不爽就拉着产品总监开始怼的人飘过。。。
就是事多,有本事多问问技术,少 BB 有的没的。

槽神 回复

又学到一个面试小技巧😂

😛 为啥不反思一下,是出需求,曾清需求的人的问题???????连自己的需求都说不清楚的人,还要开发、测试给他擦屁股?

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