被刚转正的测试弄的不厌其烦，求各位支支招

你的提测范围是否明确？

你是否能保证无 bug ？

能否提供修复 bug 的影响范围？

如果无，那这是珍稀种测试

求求了 我希望我 qa 也这样

评论里都是明白人啊

我遇到过两种，这两种人都有问逻辑的情况，区别是
第一种最终提的 Bug ，测试的方法等，和问的问题没有任何关系，Bug 质量不高，基本都是哪儿歪了，哪儿不好看，但是就是问题特别多，最后发现他只是做给不懂技术的领导看的
第二种就属于目的不是完成工作，而是提高项目质量，有次提了个内存泄露的 Bug ，因为影响不大被开发搪塞了，他最终提的 Bug 直接指出哪段代码，哪个资源重复创建对象。他的 Bug 哪怕是出现概率特别低，也描述的明确详细，开发很容易就能定位

你不要给我们吧，巴不得

祝一楼以及点赞的各位在职业生涯中被负责到底

如果那测试想跳槽，务必联系我…

@zwdsix 还有你这种所谓的「祝福」我可以认为是恶意的吗？

这贴我得收藏起来 随时鞭策自己……

建议配合。。。我都是主动跟测试说这个问题是什么原因导致的，怎么解决的

很多时候开发想要的只是字面意义上的“测试”队友，就如 OP 所想。

其实正规团队里的测试角色，有个装 B 的名称叫 QA （ quality assurance ），这才是测试角色存在的本意。

从专业角度来讲，这是人家的工作经验啊，学习能力强的，下次测试遇到相同或者相似的问题，反馈给技术时可以帮助定位到一定范围

上个公司，组里只有一个测试，他的职责就是写 pipeline 上面的各种测试代码。每次 pr 通过合并了之后，把 jira 任务移到 ready for test 之前，会有一个 desk check 。这个会上唯一事情就是给我们这个测试讲清楚我们是怎么实现的，他好写集成测试。

有可能是你太菜了，配不上她。

你把她的简历和联系方式发出来，我帮你解决问题

这样的测试，我喜欢

@IvanLi127 你的观点很好，你可以保持，我不和你争吵。从测试的角度，测试知道逻辑才是最合理的。开发能做全测试，那就别提测。片面测这个真刷新了我对开发的思维的认知。

主要还是颜值问题

这种测试请给我来一个

对 change 的说明本来就应该写在 PR 里的

额外的流程就应该额外协商，当然这种事没发生在自己身上都可以拿大棒随便敲。