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

突然感觉 ta 挺负责的

建议配合

她在引起你的注意

挺好的，很负责啊。

真想挖过来

正确的测试方法.

这样的测试，你还不要？

@Morii
@baoyinlei
@optional 关键太烦了，每解决一个她提出的 BUG ，还要跟她说解决的逻辑。她前几天还问我，为啥我们后端都不愿意跟她说 BUG 解决的逻辑。

正确的，只有她；错误的，除了她。

@kusiruu 女人，你在玩火 [狗头]

这么厉害负责的测试你居然嫌弃，我觉得是你的问题

没用 git 吗，每次 commit 记录写清楚当次更改就行了，感觉没啥毛病

对于测试来说，这是个黑盒
你操作过黑盒就知道黑盒多恶心了 对着黑盒干活有多累

这个我觉得没毛病啊
如果真的是很专业的测试 知道你的实现思路 知道你的表结构 然后人家要知道 bug 的原因 也算合理

这是个好测试（至少从她的测试行为上看）。如果她只是给点两下就说测试通过了，那才是对交付质量的不负责。

@ql562482472 这个我理解，但关键是我们公司不要求黑盒测试呀，也不要求白盒测试。只要普通的测试就可以了。

神仙测试

@itechnology 不懂珍惜啊，可以透露下什么 title 不，senior ？

这个测试懂程序？可以理解为负责，也可以理解为她想多学点开发的内容。话说你们把 issue 转为已解决时，都不贴 gerrit 的解决链接和描述问题点以及解决办法的吗？

人型小黄鸭，建议好好讲，即锻炼了表达能力，又落得个好名声。

我们没有测试，出问题了然后背锅

这不就是她的职责吗？你如果嫌麻烦，你和领导说你自己保证自己的质量，不需要测试得了

正确的，建议 reviewer 直接加上她

@Vindroid 她不懂后端语言的。我们后端把 issue 转为已解决时不需要贴 gerrit 的解决链接和描述问题点以及解决办法。小公司没有这么规范，都是解决了，git 的 commit 写一下解决了什么 BUG 就行了。

如果测试真做到这样，并有做非常详细的记录，就珍惜她吧，
有时候你改了一个 iPhone7 下 safari 适配 BUG ，但是可能在某度浏览器下，又没有这个 BUG ，
如果出了一个大的事故，可能测试的记录，能加速定位 BUG 。

总比让你带着 bug 上线好

神仙测试，不出问题你嫌弃，真出大事了你们会后悔没好好珍惜的
如果她真的能找出很多 bug ，而且只有她一个这么突出，预测后面她会很快晋升

@itechnology 那你可以把解决问题的过程解释的越详细复杂[del]折磨[/del]咯，让她 handle 不了咯

如果每个问题都需要开发向测试解释一遍前后逻辑，这也太没效率了。。。两个方法，1: 协商只有符合某些条件的问题才需要这个过程； 2: 让测试自己去看 git 提交记录

要么把她简历给我？

很不错的测试

@buyan3303 #26 其实呢，可以当成小黄鸭测试法 也不是不可以。

把联系方式晒出来, 被挖走就不烦人了.

@lululau 我就是觉得太没效率了，解决一个 BUG 都要花时间跟她解释一下逻辑，有时候跟她说，她还不一定听得懂，然后又要换一种方式跟她说。

你们公司不配她惹

虽然她很负责，但是这么做就会增加别人的负担
公司可以找一个懂那些东西并且话少的测试，这明显对效率至上的公司更有利

这种情况需要她的能力足够强，能够听懂你说的逻辑问题和解决点，否则算是负担了。

有没有想过是你们的流程不合理的问题， 不是测试的问题

让她做黑盒测试, 不要老想着白盒测试

因为你滥竽充数

想到一句话，天鹅在鸭群

@itechnology 这个测试很不错，不过可能呆在你们公司的话，这样会废了，如果你们公司不能给她一个比较好的培养环境，跟这个测试说一下，让她联系上面的这些人，去一个更好的环境培养。

git 权限给她

是不是长得不太行？不然这难道不是两全其美的好事吗

我知道为什么你讨厌她，因为她不够年轻漂亮。

如果不管什么 bug 都要解释一遍的话 确实有点浪费时间 有时候改一个 bug 10 分钟 可能解释得半小时 如果还是那种解释一遍听不懂那种 那更费时间了

你抱怨她询问你解决 BUG 的方式,不如想着怎么减少 BUG.这样不是更好吗?
是因为之前其他人不负责任,就觉得这个测试吹毛求疵吗?
做好自己份内的事.

@ylls 有些小模块出问题 一解释就得从大了说起 不然听不懂

很负责任的测试

可以发一下她联系方式... 我这边还真的招...

有联系方式吗？

我非常喜欢这样的测试

她想做测试工程师，但是很多公司只需要一个测试，不需要工程师

你不讲就行了啊。不会是欲拒还迎？

这个测试确实负责，但这种负责对于双方来说都是需要消耗大量精力的。

建议和她进行沟通，达成一个一致的目的。每次修改完 bug 让验证的时候，在当前 bug 的备注信息中尽量使用一句话给对方讲清楚如何修改好了这个 bug 。

可以跟他说，临下班的时候找半小时统一讲，上班的时候不能打断思路

不过我觉得这样的测试还挺好的，总比瞎测一通强

你嫌问的烦，那就直接把你改动的逻辑说明写好，在她问之前先发给她。你把解释当成写文档，写文档你总不至于嫌烦吧。

理论上她知道逻辑能够更好的测试. 不然就需要摸摸摸摸摸摸.....

如果测试理解能力正常，我会很乐意跟他分享 bug 的原因和修复的逻辑。
花费时间长只有两种可能，一测试智商有问题，二我智商也有问题，表达不清楚。

可以让她学学后端语言，美其名曰拓宽自己的能力。
她不是想知道你修 bug 的逻辑么，到时候直接甩给她提交的 commit ，让她亲手来给你 review 代码！

有联系方式么？楼主在哪里？

真负责的测试，而我遇到的很多测试，都很随意，有时候我还主动跟对方说哪里出的问题，改了哪里。遇到楼主这种测试，好好珍惜吧，时间久了，你的沟通能力、语言表达能力都能锻炼出来。

你可以在改完 BUG 提交给她的时候，把她想要的写成文档都给她。甚至能帮不养成一个好习惯。作为一个局外人，我觉得挺好的。

很负责的测试，你觉得很烦会不会是因为流程不够完善呢。像我们开发的时候时候，评审，方案落地都会带上测试一起让他们知道大体的流程。测试阶段，测试会有测试用例评审，测试提出用例，开发来评判用例对不对，能不能覆盖到修改点，流程完善的情况下，对双方都好。
什么不都跟测试说，只丢给需求给测试，有让测试背锅的嫌疑。。。

身在福中不知福

时间很紧张的话，这个东西解释起来很烦的，还有一个问题就是如果没有语言基础的话，解释起来她也似是而非的，如果按照开发的思路来测试，开发的自己验证就够了，有自己的思路才能验证出更多的问题；

这是正常流程啊,我们团队的 mr 入库必须给测试提供: 改动逻辑 /范围 /和影响面,你想想,如果测试不知道你这次的改动逻辑和影响面,那他怎么知道你这次的改动他要验证哪些内容(做 A 功能很有可能影响原有 B 功能),不然把整个应用全部都验证一遍吗

改 bug 都要走 jira 吧？
jira 上把修改逻辑写好不就完了

我们 pr 都会带上 ta review ，这是真的神仙测试啊

很难认可你的想法

遇到这种测试真要珍惜,出过一次线上事故就懂了

她，真的很好

很负责

简历给我，内推费给你，谢谢。

不错的摸鱼条件 珍惜

给懂的讲和不懂的讲是两回事, 不懂的你讲之前是不是还要给他普及一下基础概念, 非常麻烦的.

op 取暖失

请珍惜

你们提交代码不带 BUG 单号？完全可以让她直接去看变更记录

我们测试也会问什么原因，怎么解决的，似乎是他们领导强制要求记录的。

我觉得主要还是长得不乖

直接让她看 commit 不就行了吗

如果可以的话，建议批量引进这样的测试

简历发出来 让他来我们公司烦人

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

开发周期长、时间充裕的情况下, 测试这么做没问题.

反之, 你们需要的可能是黑盒测试, 测试人员不需要关心代码, 只需要关心操作导致的程序行为是否正确. 国内非金融业务应该大部分都是这鸟样, 程序能跑就行...

最恶心的就是 开发周期短 + 禅道要填完整的 issue 单(基本相当于把白盒测试要做的要写都都丢给开发写, 一整页下来都是必填项), 只能对这种环境说, 吖屎啦你!

神仙测试，建议珍惜，错过了有可能这辈子都遇不到这么好的了。再说回来，如果你觉得麻烦，公司规模不管如何都会觉得没必要。

这不挺好的嘛，我们公司有个这样负责的测试，线上出了 bug 她都能直接回复，还能告诉我怎么改

ticket 写清楚让她自己看去

工作时间出点力，好过休息时被抓壮丁啊...

要先问清楚，是白盒测试还是黑盒测试。如果是白盒，丢源码过去，如果是黑盒，拒绝回答，理由就是保证测试工作的顺利进行。

估计这测试不漂亮，否则不会烦她

好测试啊，她应该当测试组长的。我们这边也是这样，测试能看懂代码，提测之后人家直接 review 代码...真能发现不少代码里的逻辑漏洞。

作为一个从做项目转到测试的人来说两句，我是做业务测试，也不分黑盒白盒，就一个要求，确保线上不出现 Bug ，如果就做流程测试，把所有流程分支都测试到了，一样会出现 Bug ，因为线上数据各种各样，测试环境不可能完全复盖（起码我们的是），为了不出或者少出线上 Bug ，只能去通过业务逻辑理解去找可能出现的问题点再制造对应数据去验证，久而久之就是测试比研发更熟悉业务（研发只负责个别微服务，测试要测所有业务，业务之间的关联研发可能考虑不到），OP 说的这种测试应该是因为对产品不够熟悉导致了问的比较多，一旦对产品足够熟悉，日常提提建议，怼怼研发家常便饭，同样也能很大程度上降低线上 Bug 的出现，“先培养，再利用”，属于先苦后甜的类型吧，个人经验，供参考。

真的可以把她的简历推给上面想招这样测试的人，他们找到了想要的人，你提升了效率，两全其美...

建议少写 BUG ，这样就不会被烦了（

她其实是在学，学会了就转后端了

说明你们裸奔开发非常好，值得成为业界标准。
不走流程非常快，不总结错误省时间，遇山开山，水来土掩。顺其自然大法好。

要么保证没 bug ，要么就耐心把怎么改的告诉 TA 呗。