Qtest测试之道 有这样的测试,开发只能献上膝盖

360Qtest团队 · 2019年01月14日 · 最后由 yanying.yu1025 回复于 2024年04月23日 · 13596 次阅读

小编:以下对话是我们测试工作过程中耳熟能详的对话,作者的处理方式看似诙谐搞笑,其实仔细想想都是奔着把问题解决的方向去沟通的,所谓的 “情商”,“沟通表达能力”,处处体现在工作细节当中,大家觉得呢?

1. 当开发详细询问 bug 场景

  • 错误做法

    直接回复开发:“bug 管理系统中写得非常明确,自己回去仔细看。

  • 正确做法

    • 首先,询问开发是否已经查看 bug 管理系统的 bug 描述和复现步骤。
    • 如果,开发没有查看 bug 描述,告诉开发在 bug 系统中已经详细说明 bug 的复现步骤。如果再有不明确的地方,可以随时沟通。
    • 如果,开发已经查看 bug 描述,还是有不清楚的地方,那么需要针对有疑问的地方进行详细解释,或者当面沟通。
    • 最后,需要反思自己提交的 bug 描述和 bug 复现步骤是否清晰明了。提交 bug 的时候,做到描述详细,清晰明了。如果是 UI 方面的 bug,可以附上截图。自己附上造成 bug 原因更好,有助于开发定位 bug。

2. 当开发自测不充分,产品有严重 bug 阻碍测试

  • 错误做法

    直接找开发 leader 反映,或者直接和开发吵架。

  • 正确做法

    • 在提测系统中,将本次提测打回,注明理由 “冒烟测试未通过,出现严重 bug,阻碍了测试进行”。
    • 找开发沟通,告诉开发冒烟测试未通过。详细告知严重 bug 复现步骤和发生原因。
    • 并且告知开发,该 bug 严重影响到了测试工作开展,希望开发修改 bug 充分自测之后,再提测。

3. 当开发实现的功能不符合产品需求

  • 错误做法

    按照开发的逻辑走,视而不见。

  • 正确做法

    • 首先自己对产品需求进行客观分析,如果产品需求是合理并且经过事先评审,那么提 bug 给开发,并且告知开发原因。
    • 如果开发对产品需求有异议,并且执意按照自己逻辑的开发,那么可以拉上产品一起,进行三方沟通,达成最终方案。

4. 当开发偷偷改代码,直接上线出现了 bug,求助你时

  • 错误做法

    开发的锅,自己背。

  • 正确做法

    • 首先,提醒开发进行版本回滚,尽量避免线上影响。
    • 然后,和开发一起找 bug,并且分析 bug 原因。
    • 最后,回顾整个事件,告诉开发直接上线的风险所在。并且推动上线流程体系完善,只有测试完成并且无修改之后才能上线。

5. 当开发修复 bug 不积极,导致项目延期风险,需要你陪着加班

  • 错误做法

    让开发独自加班,对项目延期视而不见。

  • 正确做法

    • 首先,还是明确告诉开发,他自身 bug 修复不及时,导致项目有延期风险。
    • 然后,从项目角度出发,陪同开发加班,对 bug 进行回归测试和验证,保证质量的情况下,尽量不拖延项目。

6. 当开发因为你的 bug 误报,鄙视你的时候

  • 错误做法

    直接怼开发,居然怀疑自己的专业素养,大吵一架。
    非得将黑的辩解成白的,坚决否认是 bug 误报。

  • 正确做法

    • 首先,承认自己的工作失误,然后给开发说抱歉自己误报了。
    • 并且请求开发一起帮忙查找真正的原因。
    • 自己学会总结分析,bug 误报的原因。尽量避免再次误报。
    • 努力提升自己的专业素养,树立自己的专业形象。

7. 当开发因排期紧张,有些 bug 不修复,直接带 bug 上线

  • 错误做法

    直接放任开发上线。

  • 正确做法

    • 需要对不修复的 bug 进行评估,如果是影响范围极小,并且偶现性 bug,可以考虑排期的情况下允许上线。
    • 如果 bug 严重级别较高,并且影响范围大,坚决要求开发进行 bug 修复。然后才能上线。

8. 测出一个 bug 时

  • 错误回答

    1、你这里有一个 bug,快修吧
    2、你这代码写得也太烂了
    3、你又出 bug 了,怎么回事

  • 正确回答

    • 前提:先排除测试环境、未提测等相关问题;
    • 回答:hi,***,我这里遇到一个问题,你能过来帮我看看我哪里是不是操作不正确啊。

9. 当开发不能复现 bug 的时候

  • 错误回答

    1、我这可以啊
    2、你操作步骤不对吧
    3、你看看 bug 中我的操作步骤
    4、这么简单你都复现不了

  • 正确回答

    • 前提一、确认开发与我的当前测试环境是同一版本
    • 前提二、在 bug 描述的时候清楚的写明 bug 复现的步骤与输入的参数
    • 回答:这个 bug 不是一般场景下必现的,操作的步骤有点复杂,我在发现这个 bug 的时候同样的操作步骤也不是每次都出现,我把发现 bug 的步骤一一列出来,然后你试着在你的环境下操作一下,如果不能必现,再来我这测试环境看一下,我先保留这个测试的场景。

10. 开发提测明显不符合质量要求

  • 错误做法

    哎,将就着测吧,通通提 bug 呗
    埋怨开发提测的啥玩意
    嘲讽开发,比如你这啥水平啊,是不是技校毕业的

  • 正确做法

    • 开发提测后进行冒烟测试,发现主要流程无法走通,冒烟测试不通过,将冒烟测试报告发送给开发,抄送相关产品负责人员等,将冒烟情况说明在测试报告中,为保障后续的测试进度与流程,望相关开发人员尽快修复问题,保障产品按时提测,进行测试。

11. 当开发推脱忙拒绝 case 评审时

  • 错误回答

    1、不评审出了问题你负责啊
    2、有啥忙的,平时也不见你这么忙
    3、那就不评审了呗

  • 正确回答

    • 测试用例的编写是从需求文档分析中提取本次的测试要点,项目开发过程中对于技术的具体实现是否与产品需求一致,希望你(开发)与产品一起参与一下评审,这样我们从不同的角度去过一遍测试用例,为了保障测试用例的覆盖度,提前将未从技术实现的细节考虑到的用例暴露出来,这方面还就需要你参与一下,如果实在没有时间评审,我们就邮件进行一下用例评审,我将测试用例发出,你看后回复一下邮件也可以。

12. 当开发反复修改 bug 不正确时

  • 错误做法

    1、埋怨开发啥水平啊,改了几次还是这样
    2、让别的开发替改
    3、抱怨,干脆不测得了

  • 正确做法

    • 将这个 bug 出现的场景参数一一列出,调用的接口等描述出来,查看开发代码,将 bug 出现的问题帮助定位。

13. 修改 bug 引起别的 bug

  • 错误回答

    1、让你改一个 bug,你还整出 2 个 bug 了
    2、你这也太不认真了吧
    3、再这样下去,测不完了

  • 正确回答

    • 刚才的 bug 修复之前这块是没问题的,当这个 bug 修复后,这个模块的这个功能异常,引起了这个问题(将这个问题描述清楚场景),是不是这 2 个模块耦合度有点高,咱们看看这两个模块吧。

14. 当有人问你在不在的时候

  • 错误回答

    1:干嘛
    2:?
    3:不回复并假装不在
    4:回复奇怪的 gif 表情
    5:不在

  • 正确回答

    • 到!

15. 当开发找你复现的 bug 的时候

  • 错误回答

    1:操作步骤在那儿,瞎吗
    2:必现的 bug 你都复现不了,撒币吗
    3:一个微笑的表情
    4:反正 LOG/抓包已经在那儿了,剩下的自己看着办吧
    5:你来打我呀,你来打我呀,呵呵呵~~~

  • 正确回答

    • 我操作步骤是不是写的有歧义,哪儿看不懂的我下次提的时候再多注意一下,这个 bug 我是这样复现的。。。

16. 当开发很难复现一个 bug 求助于你的时候

  • 错误回答

    1:我也复现不了
    2:LOG/抓包已经给你了,别再来烦我
    3:撒币吗
    4:你自己的事情,自己看着办
    5:忙着呢,没空

  • 正确回答

    • 这个 bug 很不容易复现,我提交之前尝试复现了 1 个小时没有出现,所以先提交 bug 以防忘记,但没有关系我尽量帮你复现,你先稍等一会,看看其它 bug。(2 小时候后再联系一下这个开发不要太快联系否则难以表现出你已竭尽全力)这个 bug 我还是没有复现,从日志\抓包不能定位原因吗?我们找一下产品,看看能否先将它 later,等后期我再次复现之后咱们再尝试解决,你觉得怎么样

17. 当开发因手潮/失恋/喝多等某些神秘原因将为测试的服务端代码上线并出问题的时候

  • 错误回答

    1:这么低级的 bug 你也能出?
    2:就是喜欢不测试就上线是吧
    3:会不会写代码?
    4:你自己承担责任吧
    5:先过来跪着

  • 正确回答

    • 嫑紧张,我们的线上监控系统已经第一时间发现了问题,代码回滚及时,对线上影响不大,你把代码再自查一遍,然后发布测试环境通知我测试,测试通过之后再上线,我们再回归验证

18. 当遇到突如其来的代码改动通知你紧急测试的时候

  • 错误回答

    1:没时间
    2:早干嘛去了
    3:你咋不上天呢
    4:上去捶开发一顿
    5:竖中指

  • 正确回答

    • 嗯嗯,你这块的代码优化对后期功能扩展或性能等有很大的改善,我也很想马上给你着手测试,但目前我手头还有一些比较重要的需求还需要测试,我尽力加快测试进度,看看你这块的测试能不能稍微延后一下,你也着急的话咱们一起找产品确认一下怎么样

19. 当遇到虽温馨感人但明显不合上线标准的 bug 的时候

  • 错误回答

    1:上不了
    2:改改改!这么多 bug 上个屁!
    3:上线让领导发现这么多问题会扒了我们的皮的
    4:我们 QA 说了不能上就是不能上
    5:抄家伙

  • 正确回答

    • XX 神,你的这个功能还有 ABC 操作下崩溃的问题,acb 操作 F 页面也显示异常,问题确实比较严重。上个月 XX 领导使用 N 产品的时候发现了一个按钮适配问题,大半夜把开发测试全部拎起来改 bug 发版,批了好一通呢,你是不是也听说啦?
    • 咱们还是改完再上线吧,真的很不好改吗?但这个两个 bug 确实还是要修复的,要不咱们跟产品商量下,把这个需求先剁了?

20. 当开发要求你陪着加班但你确实没有必要陪着的时候

  • 错误回答

    1:滚犊咋!
    2:你给我钱啊?
    3:假装晚上约了姑娘
    4:我没空你找别人吧
    5:就你这破玩意哪还需要我盯着啊?

  • 正确回答

    • 唉!实在不好意思我今天晚上家里有点事,但你放心我在家也能测试,都是客户端改动,不涉及测试环境,人不在公司但效率胜似在公司!一定能让你满意,放心啦~

21. 当遇到一个总是不接电话,不回信息,毫无责任心且总出 Bug 的队友的时候

  • 错误做法

    1:帮他隐瞒 BUG
    2:帮他测试 BUG
    3:去厕所哭泣并被保洁发现
    4:回家和老婆吵架或打孩子
    5:辞职

  • 正确做法

    • 建议领导换队友同时递给领导一堆可靠的简历并嘱咐领导及时兑现 “推荐奖”

22. 当开发有一个紧急要上线的需求马上需要你测试一下的时候

  • 错误回答

    有啥紧急的
    没时间
    一会儿再说

  • 正确回答

    • 好的,收到。

23. 当开发向你要自测的用例的时候

  • 错误回答

    没有
    你最了解,你自己写吧

  • 正确回答

    • 我把咱每版的用例都总结放在 case+ 上,已经帮你开通了权限,你随时可以登陆查看。

24. 当产品需求不明确的时候

  • 错误回答

    1.需求不明确,没法测!
    2.产品经理基本的工作都没做完,原型都没有就来提测?
    3.把你 leader 叫上,我们一起聊聊这个需求?
    4.你想清楚再来找我
    5.我就按目前你提供的资料测了,出了问题不怪我

  • 正确回答

    • 这么幸运又接了某某帅哥/美女的大项目啊,我捋了一遍你提供的资料,但是还有 1、2、3、4、5、6 点方面没清晰理解你的需求要达到的预期,你再整理整理,丰富下需求,然后叫上开发我们一起评审下,一起努力把这个某经理(对产品经理尊称)这个项目做好呦(戴高帽,让产品经理承担其职责~)

25. 当开发不配合测试的时候

  • 错误回答

    1.既然你不配合,那我们中断测试了
    2.开发提供可测的版本是职责所在,你这样没法合作啊
    3.这块逻辑出了问题你负责
    4.某某开发就很好沟通,人和人的差距怎么这么大呢
    5.你是不是瞧不起测试同学,咱们走着瞧

  • 正确回答

    • 某某开发,这是我们昨天一起评审过的测试场景(让其承认该测试点的必要性),根据你们现在提供的资料,某某场景的验证所需数据需要模块披露出来(一定要详细具体,不能模棱两可),这可能给你带来一定的工作量(承认其工作量,不能说这还不好加嘛)。之前需求在这块出过问题,领导也很关注这次上线效果,所以场景是这次项目重点关注重点之一,为了咱们的项目高质量上线,辛苦了,你这边加好后,在项目群里说一声~~

26. 当遇到温馨感人,没有走正常项目流程的需求要提测,而你又排期紧张的时候

  • 错误回答

    1.没走排期,没时间
    2.需求评审,设计评审,case 评审都没做,我测不了
    3.回去写 MRD
    4.为啥你每次的需求都又紧急又重要,质疑对方的需求
    5.这是规定,我也无能为力

  • 正确回答

    • 你看我手头现在的工作(一一罗列清楚,向其表明自己现在排期紧张),心有余而力不足,你这个需求优先级提高的话,某需求进度可能受到影响。这样吧(给出解决方案),我跟某某需求的项目经理沟通下,他的需求能不能先 hold(你插队不能只跟我商量,还影响他人的需求),先跟你这个需求,然后加班把在跟需求的进度赶回来(让产品知道我们是要付出成本的)

27. 当开发要求你加班但是确实没有必要陪着的时候

  • 错误回答

    1.你们自己加吧,开发完自测好了再找我
    2.加你妹
    3.不行,我还有别的事
    4.你为啥不能提前赶赶进度,每次都是你这块拉后腿
    5.你报项目延期吧

  • 正确回答

    • 唉!实在不好意思我今天晚上家里有点事,但你放心我在家也随时待命,相应迅速。一定随叫随到,放心啦~

28. 当遇到一个态度不积极的产品/开发的时候

  • 错误回答

    1.还想不想上线了
    2.我得找你们老大聊聊,你这工作态度太不积极了
    3.群里 @,或发群邮件,施加压力
    4.这项目还做吗
    5.坐视不管,留证据,然后一天两天过去了,说因为某某沟通原因,项目延期

  • 正确回答

    • 某某,之前在蓝信群给你发的问题大家还等你的高见呢,有结论了吗?这个项目进度目前因为这个问题 hold 了,项目有可能 delay,你尽快抽时间看下,我们这边也努力配合往前赶赶进度,尽量降低 delay 风险,老大一直盯着这个项目上线效果呢,延期的话可能影响略大呢

29. 当下班的你接到电话需要紧急支持某需求时

  • 错误回答

    1.我 *** 落公司了,你找找别人吧
    2.啊,我在和朋友吃饭呢,菜刚上
    3.这个需求也没那么紧急吧,明天上班再看
    4.不行,我都下班了
    5.哈哈,这个啊

  • 正确回答

    • 稍等我先找个安静的地方,让对方把需求描述清楚(确定需求内容,是否紧急,听完后如果需求的确很紧急),先跟对方把需求涉及的重点模块和可能出问题的点讲清楚,然后看项目需要沟通的成本,如果沟通环节很少,需求很明确,就在家 *** 支持,如果涉及多方内容,就赶回公司现场支持,效率怎么高怎么来。

30. 当开发修复 bug 速度很慢的时候

  • 错误回答

    1.你能力行不行啊
    2.就差你的 bug 没修了,速度点,大家都在等你
    3.你在忙什么呢,这 bug 提了好几天了还没修
    4.干等
    5.找同组其他开发同学修

  • 正确回答

    • 最近应该挺忙吧,可能没注意到我提的某个问题。这个 bug 在测试环境活了 3 天了,你打算啥时候 kill 它啊。我之前接触过这块的业务,我猜有可能是 ** 的问题(定位到问题发生原因),可能不全面,仅供参考哈(给开发留足面子,也同时一定给开发指明发生的具体原因,帮助其快速定位并修复 bug)

31. 当产品给你的项目没有需求文档的时候

  • 错误回答

    1. 没文档,那这活我干不了
    2. 本宝宝并不是很想理你
    3. 无所谓的啦,那我也就随便测测啦
  • 正确回答

    • 如果项目非常紧急且改动不大,需求可以先与开发和测试口头信息同步,在项目上线后再补充需求文档。如果项目不紧急且改动很多,请产品不要偷懒,做好自己的本职工作。

32. 当项目明明还有很多 BUG,产品还要求立马上线的时候

  • 错误回答

    1. 想上线?都 TM 给我改了!
    2. 无所谓的啦,爱上上,关我屁事的啦
    3. 我还是个宝宝,我也不知道怎么办呀
  • 正确回答

    • 邮件告知项目所有相关人员,项目此时上线,列出 123 等 N 条风险,如果产品或领导确认风险可接受,那么可以上线。

33. 当开发进度出现延期的时候

  • 错误回答

    1. 干什么吃的!
    2. 无所谓的啦,反正你延期我也延期喽
  • 正确回答

    • 反馈产品,一起找开发确认原因,根据原因商讨对策,是整体项目延期上线还是砍需求。

34. 当开发给你扔来一个冒烟测试都无法通过的版本让你测试的时候

  • 错误回答

    1. 我告诉你!我忍你很久了!
    2. 无所谓的啦,大不了
  • 正确回答

    • 立即打回,请开发先做好自测,确保主流程功能通过再交付测试。

35. 当开发的 BUG 越改越多的时候

  • 错误回答

    1. 谁面的你?
    2. 无所谓的啦,反正着急的也是产品
  • 正确回答

    • 如果是新手开发,反馈开发领导多关注一下新人的培养,同时自己尽量帮助他快速熟悉业务。如果是熟练开发,反馈开发领导此人最近状态有问题,可能是压力大也可能是有跳槽的风险。

36. 当开发对你态度很恶劣的时候

  • 错误回答

    1. 正面硬钢,直接干架
    2. 去厕所哭泣并被保洁发现
  • 正确回答

    • 如果开发态度恶劣是常态,反馈开发领导,如此下去是没法正常合作的。如果开发偶尔态度恶劣,可以找他谈谈心,看看是不是失恋了或者昨晚把把吃不到鸡,心态爆炸。主动与开发人员维持良好的关系,就很少态度恶劣的时候了。

37. 当你在测试某一需求着急上线,产品喊你去需求评审的时候?

  • 错误回答

    1.没空
    2.改时间在评审吧
    3.你们先开,我测试完就过去
    4.放下测试去参加评审

  • 正确回答

    • 跟产品说目前有个需求紧急上线,是否方便改下时间评审。如果不能改变的话,待测试完成后在过去,前期让同事帮忙录音,或者会后再跟产品单独过需求。

38. 当你在测试某一流程,开发频繁提交代码导致测试环境前后不一致的时候?

  • 错误回答

    1.你大爷,打回不测
    2.告知 leader 开除他
    3.找开发理论,告知测试过程中不能提交代码
    4.告诉你我忍你很久了

  • 正确回答

    • 给开发说明一轮测试中是不能重复提交代码的,重复提交代码会导致测试工作的反复,最终导致项目延期。待一轮测试完成修复 bug 后,在提交代码更能提高开发测试的效率。

39. 当你测试一个不易复现的 bug,开发不配合排查修复的时候?

  • 错误回答

    1.不复现,爱咋咋地
    2.线上出问题你负责
    3.告诉他领导态度消极
    4.怀疑对方能力问题

  • 正确回答

    • 告诉他这个 bug 还挺严重的,万一上线了出现了问题,这个责任谁都担负不起。然后跟开发一块排查问题,把 bug 解决掉。

40. 当测试中涉及跨团队成员且成员之间消息回复不及时的时候?

  • 错误回答

    1.等着
    2.出现问题让本团队开发解决
    3.遇到流程性问题找领导解决
    4.问他干啥呢,不好好上班

  • 正确回答

    • 在测试的过程中找到问题的根源,并且将问题抛到群里,并且 @ 对应的开发人,让其快速解决。如果回复比较慢的话,直接单聊或者去工位找他。

41. 当开发说基本没改代码直接上线,导致线上问题的时候?

  • 错误回答

    1.自己搞,不管我的事儿
    2.静静的看着你装 X 失败
    3.呵呵哒
    4.你不是说没改代码吗,早干嘛去了

  • 正确回答

    • 跟开发一块回滚业务线代码,保证线上业务的正常;同时跟开发一块去排查问题,并且在测试环境进行测试、修复验证,保证上线后不再出现上述 bug。

42. 当开发问你在不在的时候

  • 错误回答

    不在
    干嘛

  • 正确回答

    • 在,有什么事情吗?

43. 当开发不认可你提的 BUG 时

  • 错误回答

    你懂个 P,老子是专业的
    你这水平还干开发?
    爱改不改

  • 正确回答

    • 这个问题是这样的,你要站在用户的角度去理解,不能以开发的角度看待问题,这个 BUG 已经严重影响了用户体验,需要修复。

44. 当开发偷偷修改测试环境代码时

  • 错误回答:

    你再动一次试试
    你自己测吧

  • 正确回答

    • 这次测试请不要修改测试环境代码,并且从下一次开始,环境需要我们来维护~

45. 当开发的提测冒烟都不过时

  • 错误回答

    你赶快修一下,我们着急测试
    你会不会写代码,需要老子教你吗

  • 正确回答

    • 您的提测被打回了,冒烟不过是不接受测试的

46. 当你让开发用的测试平台去进行测试而开发不愿意的时候

  • 错误回答

    好吧,我帮你测
    你是不是傻,学不会?
    我要告诉我领导

  • 正确回答

    • 我们的平台可以完美解决你的测试需求,并且操作非常容易,可以提升我们的工作效率,请你使用一下,有问题随时问我。
共收到 49 条回复 时间 点赞

我只感觉到满屏的测试是保姆的感觉,工作职责都有明确,凭什么搞得保姆一样

我发现一个和需求不一样的地方,是不是我测试有问题,你能不能看一下?

😂 感觉测试好委屈,是这样一直委曲求全吗

意思是怂就完事儿了嘛😂

哈哈,我一般都要求测试对开发和产品都要强势一点,质量的推进是需要革命的精神,又不是请客吃饭

哈哈哈,那些错误的例子感觉像是搞笑指南

什么时候写一个 有这样的开发,测试只能献上膝盖

666,

这个吊样一定是测试地位低到天坑了吧

一个字 怂

感觉测试是项目经理的职位了,一直在协调,关键是人家听你的吗

可以看成指桑骂槐吗,灰色的部分感觉 66 的

😆 ,就差没跪下叫爹,求着定位问题,求着改 BUG。

跪在地上求开发爹改 bug

虽然有很多重复的,但是整体还是很赞的,我们以前的确大部分情况下就是这么沟通的,这样沟通久了大家责任心都会比较好
当然,除了第 8、14 这两条像太监一样没尊严的……

emmm……

这得看开发人品咋样,人品不咋的真的想上去干架。

小编,你写的不全,是什么的公司环境会让你这样测试?
公司是否有严格的研发流程与测试流程?
若是开发对于自己也有同样好的认知,你写的还可以实行;
若是开发对于自己的问题视而不见,你这样将会使开发与测试之间的平衡,严重向开发倾斜。
我觉得,你的思想有点像 “女德班” 所教受的那样:打不还手,骂不还口,逆来顺受,绝不离婚。

槽神 回复

开始不怼人,少冲突,多沟通是对的。
你再看看,就算是最轻的:
当开发问你在不在的时候?
在不就结了,哪来那么多客套话。真把自己当乙方对甲方了。
当开发偷偷修改测试环境代码时
这次测试请不要修改测试环境代码,并且从下一次开始,环境需要我们来维护~
还下一次,这次不说清楚,下下次都好不了。
太怂了,领导这样,有能力来转开发吧,至少不用这么怂。(我以前领导就这个风格,呵呵哒)

个人觉得除了第 14 项外,其他都没有问题。
有的人看着觉得 “卑躬屈膝”,“逆来顺受” 的感觉,在我看来是一种比较专业的沟通方式。
对于说 “保姆式” 沟通,把一个问题描述清楚,前提条件弄明白,减少误报和沟通成本,难道不是测试人员应该做到位的吗?何来 “保姆式沟通” 呢?
有人联想到 “绝不离婚,打不还手” 的场景,想象力不错呀!
至于说沟通方式很 “怂” 的,不如挑几个问题说说你们平时的沟通方法?

(个人观点,不代表社区意见)

我一半不赞同。这样的测试地位容易降低,即使你做的本身不错。

magicyang 回复

有规矩在就行,不出事便罢了,出事了是要直接全公司通报的,我印象中以前有个开发就被通告年底考核降一级,人家主动离职了……这就叫夹带修改、跟产品经理/客户接私活,而且还不跟测试沟通,这的确很可恶~

同意 21 楼的定义:“专业的沟通方式”,的确可以这么理解,以前 PA 大学有《高效沟通》、《冲突解决》、《非职权的影响力》等一大堆类似的职业技能面授课程,类似场景案例有涉及。

我记得前段时间我说能力拆分成职业技能和专业技能,还有人 diss 我,只能感叹夏虫不可以语冰~

槽神 回复

算了,不多说了。
我推荐一个课程,台大 陈嫦芬的职场素养。

这些都是日常工作中经常出现的,但是有些问题该锤就得锤,而且得锤锤死,这些说的简直测试舔狗修炼手册

26楼 已删除

一个图不就搞定了吗?

舔狗最终一无所有 该强势的地方就得强势

29楼 已删除

误人子弟

31楼 已删除

和人沟通讲究先抑后扬,你上来就委曲求全开发真就合计你是舔狗了,就像谢娜怼她的官方粉丝一样,以后往死了用你还鄙视你。
不是说这些话术不对,而是有点儿太 low 了。
以我的做法,肯定是要喷这个开发,让他知道我们测试不是好惹的,然后做人留一线日后好相见,抬一手,然后这个事情最好让自己领导和开发领导都清楚过程,把事情做漂亮。
还开发私自提交搞出 bug,测试还要一起加班,也太 low 了,测试可以加班,但是不是你开发让我加班的,你能给我调休或者加班费吗,你有这个权力吗,我就没有其他事情了吗,这种事情肯定要搞到各方领导都知道的,要不然师出无名。
最后,建议这种公司的测试注意自我学习,提高自身能力,及时跳槽,因为能搞出这种话术的,连基本的心理都搞不明白,说白了就是连舔都不会舔,啥也学不到。
舔开发没用,要舔的是 KPI,共勉。

这是面试的时候说的话吧😆 😆
有这么无私的测试?我没见过

遇强则强,怼就完事了,对事不对人
舔狗一无所有

zyanycall 回复

你好牛逼哦

站在项目角度、客户角度,有问题解决问题,资源总是有限的,一定是有取舍的,至于具体的措辞态度,对人下菜了,毕竟有的开发喜欢攻,有的开发喜欢受

说那么多干啥,盘开发就完事了

有些观点同意,有些观点不同意,比如说: 当开发不配合测试的时候,当开发进度出现延期的时候,这两个不完全不赞同,就算你说好话,就算你赞同也能怎么样,也不配合测试,就延期,你怎么办,要根据具体情况而定,用不同的方式方法,该强硬的强硬,该软的时候软才是上策,没什么绝对的

开发给你献上膝盖的原因不是跪服,而是给你跪了
你这角度,太 low

“XX,帮忙看一下这个,好像 XXX 功能有点问题,多谢。”
“你先自己看下接口。”
“接口返回是正常的。”
“看下日志。”
“日志也没看到异常。”
“这个先去找前端看一下吧”
“...”

出一次拼多多最近的事故,吵一周的架就能解决的事情。调侃下,实际情况是对不同类型的开发团队用不同的策略,先礼后兵。

冲着解决问题的角度考虑,效率很高,但是如果是频次很高,错误很低级我觉得,选择 “错误回答” 也是一种正确的选择,除非你是神仙,不然累的慌

总结得到位,Mark 一下

你说的对。

写得好真实

提测不过,开发直接不给测试,直接上线~~~

萝卜 回复

这样也好,出了问题不关测试啥事

看着像交规:文明礼让开车, 怂就对了

测试得有地位和话语权,按文档说的干脆保姆算了,一点地位都没有,个人觉得测试得有自己判断和决策,该怼就怼,只有让开发痛了,他才会尊重你

回复内容未通过审核,暂不显示

通篇都是日常的问题,错误沟通很生动形象,很诙谐;正确示例所比较中肯,比较冷静客观,比较职业。

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