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

[itechnology]

是这样子的，这个测试有个毛病，真的太烦人了。你每次改完一个 BUG 让她去验证一下，她都要问你，这个 BUG 是怎么改的，逻辑是啥？是加了个判断吗？总之就是要知道后端改这个 BUG 的代码逻辑。

然后就是遇到有洗数据的 SQL 时，非要我们把 SQL 发给她看，还说她需要知道 SQL 是怎么写的，好进行测试。

这两种行为，公司所有的测试就她一个人有，跟她说，她还反驳说，其他人怎么样她不管。

我说明一下，如果是整个测试组都有这个要求，那我是非常乐意给她说这些的。现在是测试组长都没有提过这个要求，就她一个刚转正的提了这个要求。我觉得如果真有这个需求，可以先反馈给她的组长。

[fournoas]

把 Bugfix 的 git diff 发给他看就行了

[jkbspin]

为什么不考虑少写点 bug 呢。。

[hitmanx]

bug 系统里或者 code review （如果你们有 code review 的话）里写清楚。她要问的话可以把链接丢给她。

人家想学习，这个没毛病。有这样的测试，确实要珍惜。

[cpsony]

感觉是因为这个 QA 的测试理念稍微更"超前点", 已经到了测试左移阶段了, 而你们公司却还在那区分黑盒 /白盒测试, 所以显得格格不入, 建议你和她领导反馈, 让她另谋出路吧, 外面适合她的机会有很多

[xx19941215]

负责的测试，很不错啊。如果线上出了问题，她也肯定会第一时间检查的。

[wowawesome]

她还是这么负责

[OMGZui]

挺好的呀

[wupher]

不怕你笑，我有个前同事，就是这么被测试妹子给拿下。

[christin]

emmm ，本来我也觉得挺好的，但是 lz 说她听不懂。那不就扯淡么，听不懂还问个 p ，给测试讲半天还耽误开发时间。

[dolphintwo]

"刚转正"、"测试" 影响你判断了

[lueluev]

在 MR 里艾特她让她自己看啦，看不懂的再问你

[particlec]

同样情况，她会问我背后的逻辑、有时候提优化界面意见，每天催我禅道 bug ，项目赶进度的时候确实很崩溃，我很烦，但是客观来说她确实负责，上线后 bug 确实少

[SaltyMouse]

”这个我就可以理解，如果是测试组整体这么要求，我是可以理解并且乐意给她讲解的。“

[guisheng]

我之前很喜欢改了一个问题给别人分享我的逻辑和实践。后面我明白了没有人愿意多听你的闲话，也不关心你怎么做的，好了就行，没好再来找你。

[SaltyMouse]

没打完发出去了，老是忘记这里的换行不一样。如果有要求楼主是乐意的，说明楼主其实觉得她也没有错，只是想偷懒而已啦，不然就算是测试组要求，也不会乐意吧。

[Bigglesworth]

朋友耐心一点吧，有些事情刚开始会不喜欢，但是如果讲清楚了的话，也会释然，说不定你们还能成为好朋友。讲讲也能让他了解逻辑，时间长了，他也能知道个问题大概，测试效率也更高。

[zhaokun]

我之前也遇到过一个这样的测试，刚开始以为挺好，挺负责的，就给他讲编码的思路，但是他不懂代码呀，git 给他没用，他只问你代码思路，哪有那么多时间精力给他讲的那么细，最后我俩协商只给他讲复杂业务的大概思路，没必要一个 if 一个 if 的讲，讲了他也不懂

[harmless]

多好的测试，你居然嫌烦

[gwbw]

我猜 OP 烦的是给她解释花的时间对自己来说是额外成本，需要自己消化掉，影响了其他工作进度 /私人时间。从事情本身触发你也不排斥这个做法。

从这个角度，你可以把她精益求精这个事推进一下，让整个测试团队都参考她的工作模式，并提出这样对团队和个人发展都有好处，但是额外引入的成本会减慢开发速度，让领导来定夺是否需要使用精益求精的方式。

没成，领导自然会让她减小这方面的投入，你也可以名言正顺地提出意见；成了，这部分成本就从需要你自己消化变成团队成本，也达成了你的目的

[qzhai]

还是很不错的，可能这样的工作方式你会觉得烦躁，但是你习惯下把。
你要是经历过比较恐怖的线上事故之后，
你就会觉得这样的测试是多么的重要

[4ark]

100 多楼都在说这位测试小姐姐负责任，还不能说明问题吗，还是说 OP 只是上来找认同感而已。

[doommm]

个人建议把问题原因及修改的内容直接写在 bug 工单里，其它人也能看到，后面也可以帮助自己回忆 bug 解决过程

[chenshun00]

修复了 bug ，把原因跟人描述一下不是应该做的么，还需要人催，离大谱

[enchilada2020]

@gwbw 高 实在是高

[HENQIGUAI]

@Dlin #45 这楼已经讲得很明白了，可以结贴了。

[Poko]

我要是去做测试我也这样

[WishMaster]

她真的，我哭死

[rickli]

为啥改完 bug 自己不验证 要测试去验证？我公司都是要自己先验证的

[iScout]

刚转正，业务不熟悉，肯定会多问几句；
bug 改完提测，有关 bug 的简单说明，影响范围总得给测试说明一下吧；

[neptuno]

之前公司也是这样的，代码质量一下子上去很多，“不敢轻易写 bug 了”

[fogcell]

我觉得测试软件应该有自己的分工和边界。
测试去了解代码的逻辑这部分是属于增值的部分，而不是强制要求。
所以如果这个测试问这些问题而且还能直接消化软件的回复的话，我觉得那就没问题，是个好测试。
如果是单纯做这些事情，能力不够那为什么不直接去做开发呢？

[grewer]

建议发下联系方式给我, 我内推到我司

[imycc]

你说她问你“这个 BUG 是怎么改的，逻辑是啥？是加了个判断吗？”，这个我认为本来就是修复 bug 的工单里要说清楚的吧。包括 SQL 变更，不说变了啥，她测什么呢。
作为一个刚转正的新人，这个工作态度至少是没毛病的。如果她能力再强一些，值得去大公司工作。

[cue]

我想说…… 这个标题也是个 bug……

[Woood]

把她的简历地址给一下吧，谢谢

[dunn]

不要写 bug ，让他失业吧

[Psily1017]

这种测试是真正能够推动交付、保证上线质量的测试，说明在思考，如果这位小姐姐测试能够通过你说的逻辑，进而成长，得益是你们整个业务线。

[zhufeilong]

@gwbw 高 实在是高

[Stendan]

我认识的一位测试人员也曾这样，在影子库里甚至精确到每个查询的 sql 以及纯 Excel 的数据对比。直到我们相继跳槽后，又入职了一家公司，他便再也没有问过我一条 sql 了，因为新公司用了 k8s ，在服务网格中，所有的查询都是单一且多次服务调用的，以前的 left join 对他而言显然已经 "看不到了"，没有了 sql 的概念，以他目前的知识储备，除了动手点点以外也无法做其他的测试，目前团队也走向自动化测试与一部分 devops 的工作，也准备对测试岗有一些培训（自学），对他而言都是新的挑战和机遇。

对于 OP 而言，我觉得一个巴掌拍不响。当我的同事对我的工作有过多的额外时间消耗时，我通常会善意提醒下，如果对方还是喋喋不休，我会告诉 ta 把想法在群里说出来，咨询下领导的意见，通常那些说话声最大的人反而哑口无言，最后甩给我一句那就这样吧，然后这事儿就翻篇了。

[jiejiss]

这个测试放在你们公司屈才了

[K1W1]

挺好的

[lsry]

@cue 標題確實是個 bug ，OP 還是要謙虛謹慎，多學習爲好。
不厌其烦，解释是不嫌烦琐与麻烦，形容耐心。出自 清·夏敬渠《野叟曝言》第一百三十八回评：“每阅数年，必综叙素臣生子生孙，娶妇嫁女，中科发甲。而读者不厌其烦，甚至一回之中，先后数见，绝无沓冗繁复之病。”

[sch1111878]

@optional 看 op 嫌弃的样子应该不是什么大公司, 所以没有 title

[lei2j]

这样的测试哪里找

[IvanLi127]

测试知道得太多了，那不就和开发自测差别不大了么。。。

[idblife]

负责任的测试
很快就会跳槽去更好的公司

[acehinnnqru]

@IvanLi127 要测试的意义不就是开发自己测不了测不全吗。。。

[aaa5838769]

方便把她联系方式提供么。

[honamx]

挺好的，我反而觉得这个测试很负责任。如果测试能看懂代码，直接甩 commit 给他好了。看不懂就简单写一下改动点。

[anxn]

测试没毛病

[IvanLi127]

@acehinnnqru 你在说啥？测试想知道怎么改的不就是为了片面地测么？那不就和开发一样测不全么。。。。有啥问题？

[leeson666]

不厌其烦的意思是：不嫌烦琐与麻烦,形容耐心

[thomaspaine]

测试态度挺好的，但是大家似乎忽略了一个问题，这个测试按照 op 的说法似乎不懂 coding ，那换个角度看，其实是测试在通过 bug 的借口，找开发学习如何 coding 。

[kkbblzq]

你们 bug 单不用写原因和解决方案吗。。。就你描述的内容在一些公司里是 bug 单是关单前的必填项吧。
BTW ，你可以以此督促自己更加严谨，没有 bug 也就没有这事了不是吗哈哈哈

[romisanic]

这不是一个常见的白盒测试的常规操作吗？
你觉得她不正常，是因为你们团队以前不正常。

[offswitch]

@thomaspaine 学习也挺好的，可以考虑转测开，开发太卷了。

[youisme]

求简历，求联系方式

[JohnBull]

如果她负责近 RD 的白盒测试这没毛病，如果是近 PM 的集成黑盒测试，这么搞确实太烦人，感兴趣自己去看代码，没义务给无关人员做免费培训。

建议建立相关流程，避免无谓低效的口舌交流，降低项目对特定测试人员的依赖。

比如说她怀疑你是针对某个 case 加了个判断，那么就要求她写出针对特定边界判断无法通过的 case 集，与代码同源维护，最终一律在 Jenkins 上 make test 见分晓。

天长日久积累起来的带文档的 case 库，才是项目的财富

[dayeye2006199]

这个是 code reviewer ，建议分享代码库权限，并且 Bug 修复附上 PR 号

[Aloento]

直接让她来写后端就好了，很专业负责的测试
不像我自己写测试各种水...

[whajcf]

这不是正常流程吗? 要么更改详设提交给她,要么就讲清楚逻辑, 要不人家咋知道你改动影响,要回归多少测试用例或者增加用例

[Y29tL2gwd2Fy]

求联系方式

[Jessun]

这种测试虽然要求多，但是都不过分啊。我遇到这种反而很放心 —— TA 那么心细一定不会出 bug 的。

一般在做变更前，都会写明下面几条：

1. 需求背景 /问题背景
2. 解决方案 /问题原因

如果是需求，就写方案，写大概怎么做。如，xxx 服务增加 xxx 功能。或者 xxx 接口新增 xxx 判断。
如果是 bug ，就写 xxx 在 xxxx 情况下没有判断空指针引发的错误等等
（有时，写得越详细越好）

3. 该方案实施后，会有哪些变化？比如会有哪些操作？或者观察哪些特征的日志？

比如新增 xx 操作，可以通过关键字 xxx 过滤日志来观察 xxx 是否已经生效。

以上是基本的方面吧？这样，无论是自己、产品、测试或者是后来的人，一看就知道这个需求 /问题是做了什么。减少了沟通成本。

我的建议是这样的：在完成开发后，提交测试前，你就把上面的内容写好。这时候有人问你怎么做的，你就把上面的文档发给 TA ，这样别人一看就懂，就不会再提其他问题了。


好的文档的标准 —— “一个刚入职的研发 /测试 /产品”一看就明白整个过程，不会再有问题。

[asssfsdfw]

测试是跟需求相关的。告诉它实现反而可能会造成测试上的一些局限性。（黑白盒测试）
重要的是测试用例。

[acerphoenix]

我要遇到这种主动学习的，会鼓励，但顶多简单介绍，然后给他代码让自己看 diff 去，

[fox0001]

有无可能，她想转开发？

[zw1one]

找她组长

[zarvin]

肯定是妹子不好看

[gumuxi]

这样的测试，才是一个合格的测试工程师，很快他飞速成长就不会烦你了，成长起来就去更好的公司了

[justRua]

说明人家负责，我们这测试都会看你代码，测试环境有问题人家自己先看日志，然后跟你说代码 xxx 这一行是不是有问题。。。

[varzy]

为什么我见过的测试都是面向点点点测试。。。

[tw93]

这么好的测试 你就偷着乐吧

[botao1]

@itechnology 对啊，你为啥不愿说解决的逻辑？

[pkwenda]

我的日常是求着测试回归。

[softtwilight]

而且，你把逻辑讲给别人听真的会拖慢工作进度吗...

[patrickchoo]

这是认真尽责在测试呀，随便点两下的都是摸鱼 😂

[redvoilin]

@itechnology 你明显不懂测试，什么叫不要黑盒测试，也不要白盒测试，只要普通测试，啥叫普通测试？ 大部分点点点的测试就是黑盒测试

[manasheep]

我觉得测试就应该面对黑盒，不然会被先入为主的思维带偏，测试要的就是符合需求，且周全，不在乎具体实现，开发没有义务给测试讲解具体实现。

[ufan0]

看到评论区前面几条看得发抖，真如楼主所说的场景的话，这个测试简直就是离谱。

他知道业务逻辑复现场景测试用例就能处理完了，何必给双方增加麻烦。

真想知道代码逻辑就自己去找架构开 code reviewer 权限。

目前现状就是想通过你剥削你进行学习。

[manasheep]

@whajcf 想象自己是个质检员，你根本不应该知道具体调整细节，而是按标准把所有质检项目重新进行一遍，合格就放行

[Guesser]

你的提测范围是否明确？

你是否能保证无 bug ？

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

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

[yuhuan66666]

求求了 我希望我 qa 也这样

[ainon]

评论里都是明白人啊

[Musong]

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

[1018ji]

你不要给我们吧，巴不得

[zwdsix]

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

[feelinglucky]

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

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

[liuchao719]

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

[RainCats]

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

[adoal]

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

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

[miracles]

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

[caixiangyu17]

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

[horizon]

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

[Marmot]

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

[uvwlab]

这样的测试，我喜欢

[acehinnnqru]

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

[wanacry]

主要还是颜值问题

[TateLiao]

这种测试请给我来一个

[darkbread]

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

[madeworldbetter]

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