是这样子的，这个测试有个毛病，真的太烦人了。你每次改完一个 BUG 让她去验证一下，她都要问你，这个 BUG 是怎么改的，逻辑是啥？是加了个判断吗？总之就是要知道后端改这个 BUG 的代码逻辑。
然后就是遇到有洗数据的 SQL 时，非要我们把 SQL 发给她看，还说她需要知道 SQL 是怎么写的，好进行测试。
这两种行为，公司所有的测试就她一个人有，跟她说，她还反驳说，其他人怎么样她不管。
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 1469 days ago, the information mentioned may be changed or developed.
Supplement 1 · Oct 26, 2022
我说明一下，如果是整个测试组都有这个要求，那我是非常乐意给她说这些的。现在是测试组长都没有提过这个要求，就她一个刚转正的提了这个要求。我觉得如果真有这个需求，可以先反馈给她的组长。
 |
1
突然感觉 ta 挺负责的
|
156 |
2
建议配合
|
 |
3
这是神仙测试。请珍惜吧，直接把 pr/mr 加上她，一个负责的 reviewer 啊
|
 |
4
她在引起你的注意
|
 |
baoyinleiOct 26, 2022
5
挺好的，很负责啊。
|
|
6
真想挖过来
|
 |
JoooooooooOct 26, 2022
7
正确的测试方法.
|
 |
xianghaolinOct 26, 2022
8
这样的测试，你还不要？
|
 |
9
|
 |
10
正确的，只有她；错误的，除了她。
|
 |
11
@kusiruu 女人，你在玩火 [狗头]
|
 |
12
这么厉害负责的测试你居然嫌弃，我觉得是你的问题
|
 |
eason1874Oct 26, 2022
13
没用 git 吗，每次 commit 记录写清楚当次更改就行了，感觉没啥毛病
|
 |
14
对于测试来说，这是个黑盒
你操作过黑盒就知道黑盒多恶心了 对着黑盒干活有多累 |
 |
15
这个我觉得没毛病啊
如果真的是很专业的测试 知道你的实现思路 知道你的表结构 然后人家要知道 bug 的原因 也算合理 |
 |
x1kongOct 26, 2022
16
这是个好测试（至少从她的测试行为上看）。如果她只是给点两下就说测试通过了，那才是对交付质量的不负责。
|
|
17
@ql562482472 这个我理解，但关键是我们公司不要求黑盒测试呀，也不要求白盒测试。只要普通的测试就可以了。
|
 |
TsukiHaOct 26, 2022
18
神仙测试
|
|
optionalOct 26, 2022 via iPhone
19
@itechnology 不懂珍惜啊，可以透露下什么 title 不，senior ？
|
 |
VindroidOct 26, 2022
20
这个测试懂程序？可以理解为负责，也可以理解为她想多学点开发的内容。话说你们把 issue 转为已解决时，都不贴 gerrit 的解决链接和描述问题点以及解决办法的吗？
|
 |
21
人型小黄鸭，建议好好讲，即锻炼了表达能力，又落得个好名声。
|
 |
777777Oct 26, 2022
22
我们没有测试，出问题了然后背锅
|
 |
bk201Oct 26, 2022
23
这不就是她的职责吗？你如果嫌麻烦，你和领导说你自己保证自己的质量，不需要测试得了
|
 |
learningmanOct 26, 2022
24
正确的，建议 reviewer 直接加上她
|
|
25
@Vindroid 她不懂后端语言的。我们后端把 issue 转为已解决时不需要贴 gerrit 的解决链接和描述问题点以及解决办法。小公司没有这么规范，都是解决了，git 的 commit 写一下解决了什么 BUG 就行了。
|
 |
buyan3303Oct 26, 2022
26
如果测试真做到这样，并有做非常详细的记录，就珍惜她吧，
有时候你改了一个 iPhone7 下 safari 适配 BUG ，但是可能在某度浏览器下，又没有这个 BUG ， 如果出了一个大的事故，可能测试的记录，能加速定位 BUG 。 |
 |
amiee0599Oct 26, 2022
27
总比让你带着 bug 上线好
|
 |
mikuazusaOct 26, 2022
28
神仙测试，不出问题你嫌弃，真出大事了你们会后悔没好好珍惜的
如果她真的能找出很多 bug ，而且只有她一个这么突出，预测后面她会很快晋升 |
 |
weizhen199Oct 26, 2022
29
@itechnology 那你可以把解决问题的过程解释的越详细复杂[del]折磨[/del]咯，让她 handle 不了咯
|
 |
30
如果每个问题都需要开发向测试解释一遍前后逻辑，这也太没效率了。。。两个方法，1: 协商只有符合某些条件的问题才需要这个过程； 2: 让测试自己去看 git 提交记录
|
 |
GlobalNPCOct 26, 2022
31
要么把她简历给我？
|
 |
gxm44Oct 26, 2022
32
很不错的测试
|
 |
jdandelion573Oct 26, 2022
34
把联系方式晒出来, 被挖走就不烦人了.
|
|
35
@lululau 我就是觉得太没效率了，解决一个 BUG 都要花时间跟她解释一下逻辑，有时候跟她说，她还不一定听得懂，然后又要换一种方式跟她说。
|
 |
AslanFongOct 26, 2022
36
你们公司不配她惹
|
 |
37
虽然她很负责，但是这么做就会增加别人的负担
公司可以找一个懂那些东西并且话少的测试，这明显对效率至上的公司更有利 |
 |
zhuangpipiOct 26, 2022
38
这种情况需要她的能力足够强，能够听懂你说的逻辑问题和解决点，否则算是负担了。
|
 |
lazyfighterOct 26, 2022
39
有没有想过是你们的流程不合理的问题， 不是测试的问题
|
 |
lx0758Oct 26, 2022
40
让她做黑盒测试, 不要老想着白盒测试
|
 |
zhoutOct 26, 2022
41
因为你滥竽充数
|
 |
42
想到一句话，天鹅在鸭群
|
 |
43
@itechnology 这个测试很不错，不过可能呆在你们公司的话，这样会废了，如果你们公司不能给她一个比较好的培养环境，跟这个测试说一下，让她联系上面的这些人，去一个更好的环境培养。
|
 |
xuxu5112Oct 26, 2022
44
git 权限给她
|
 |
45
是不是长得不太行？不然这难道不是两全其美的好事吗
|
 |
46
我知道为什么你讨厌她，因为她不够年轻漂亮。
|
 |
yllsOct 26, 2022
47
如果不管什么 bug 都要解释一遍的话 确实有点浪费时间 有时候改一个 bug 10 分钟 可能解释得半小时 如果还是那种解释一遍听不懂那种 那更费时间了
|
 |
48
你抱怨她询问你解决 BUG 的方式,不如想着怎么减少 BUG.这样不是更好吗?
是因为之前其他人不负责任,就觉得这个测试吹毛求疵吗? 做好自己份内的事. |
 |
NineNanOct 26, 2022
50
很负责任的测试
|
 |
emricOct 26, 2022
51
可以发一下她联系方式... 我这边还真的招...
|
 |
thulofOct 26, 2022
52
有联系方式吗？
|
 |
adrianXuOct 26, 2022
53
我非常喜欢这样的测试
|
 |
54
她想做测试工程师，但是很多公司只需要一个测试，不需要工程师
|
 |
1000copyOct 26, 2022
55
你不讲就行了啊。不会是欲拒还迎？
|
 |
PichaiOct 26, 2022
56
这个测试确实负责，但这种负责对于双方来说都是需要消耗大量精力的。
建议和她进行沟通，达成一个一致的目的。每次修改完 bug 让验证的时候，在当前 bug 的备注信息中尽量使用一句话给对方讲清楚如何修改好了这个 bug 。 |
 |
InnovatinoOct 26, 2022
57
可以跟他说，临下班的时候找半小时统一讲，上班的时候不能打断思路
不过我觉得这样的测试还挺好的，总比瞎测一通强 |
 |
hakuya7Oct 26, 2022
58
你嫌问的烦，那就直接把你改动的逻辑说明写好，在她问之前先发给她。你把解释当成写文档，写文档你总不至于嫌烦吧。
|
 |
justfinduOct 26, 2022
59
理论上她知道逻辑能够更好的测试. 不然就需要摸摸摸摸摸摸.....
|
 |
60
如果测试理解能力正常，我会很乐意跟他分享 bug 的原因和修复的逻辑。
花费时间长只有两种可能，一测试智商有问题，二我智商也有问题，表达不清楚。 |
 |
joyyuOct 26, 2022
61
可以让她学学后端语言，美其名曰拓宽自己的能力。
她不是想知道你修 bug 的逻辑么，到时候直接甩给她提交的 commit ，让她亲手来给你 review 代码！ |
 |
wineastOct 26, 2022
62
有联系方式么？楼主在哪里？
|
 |
yuhuanxiOct 26, 2022
63
真负责的测试，而我遇到的很多测试，都很随意，有时候我还主动跟对方说哪里出的问题，改了哪里。遇到楼主这种测试，好好珍惜吧，时间久了，你的沟通能力、语言表达能力都能锻炼出来。
|
 |
hnbcinfoOct 26, 2022
64
你可以在改完 BUG 提交给她的时候，把她想要的写成文档都给她。甚至能帮不养成一个好习惯。作为一个局外人，我觉得挺好的。
|
 |
mockRanOct 26, 2022
65
很负责的测试，你觉得很烦会不会是因为流程不够完善呢。像我们开发的时候时候，评审，方案落地都会带上测试一起让他们知道大体的流程。测试阶段，测试会有测试用例评审，测试提出用例，开发来评判用例对不对，能不能覆盖到修改点，流程完善的情况下，对双方都好。
什么不都跟测试说，只丢给需求给测试，有让测试背锅的嫌疑。。。 |
 |
dqzcwxbOct 26, 2022
66
身在福中不知福
|
 |
yueban5521Oct 26, 2022
67
时间很紧张的话，这个东西解释起来很烦的，还有一个问题就是如果没有语言基础的话，解释起来她也似是而非的，如果按照开发的思路来测试，开发的自己验证就够了，有自己的思路才能验证出更多的问题；
|
 |
unco020511Oct 26, 2022
68
这是正常流程啊,我们团队的 mr 入库必须给测试提供: 改动逻辑 /范围 /和影响面,你想想,如果测试不知道你这次的改动逻辑和影响面,那他怎么知道你这次的改动他要验证哪些内容(做 A 功能很有可能影响原有 B 功能),不然把整个应用全部都验证一遍吗
|
 |
69
改 bug 都要走 jira 吧？
jira 上把修改逻辑写好不就完了 |
 |
yao177Oct 26, 2022
70
我们 pr 都会带上 ta review ，这是真的神仙测试啊
|
 |
VegetableOct 26, 2022
71
很难认可你的想法
|
|
unco020511Oct 26, 2022
72
遇到这种测试真要珍惜,出过一次线上事故就懂了
|
 |
fuckaholicOct 26, 2022
73
她，真的很好
|
 |
bytesfoldOct 26, 2022
74
很负责
|
 |
acerestOct 26, 2022
75
简历给我，内推费给你，谢谢。
|
 |
tkHelloOct 26, 2022
76
不错的摸鱼条件 珍惜
|
 |
MoYi123Oct 26, 2022
77
给懂的讲和不懂的讲是两回事, 不懂的你讲之前是不是还要给他普及一下基础概念, 非常麻烦的.
|
 |
kindomOct 26, 2022
78
op 取暖失敗
|
 |
ymlluoOct 26, 2022
79
请珍惜
|
 |
ztxccccOct 26, 2022
80
你们提交代码不带 BUG 单号？完全可以让她直接去看变更记录
|
 |
creanmeOct 26, 2022
81
我们测试也会问什么原因，怎么解决的，似乎是他们领导强制要求记录的。
|
 |
kevinlexmingOct 26, 2022
82
我觉得主要还是长得不乖
|
 |
terence4444Oct 26, 2022 via iPhone
83
直接让她看 commit 不就行了吗
|
 |
catsoulOct 26, 2022
84
如果可以的话，建议批量引进这样的测试
|
 |
DbinOct 26, 2022
85
简历发出来 让他来我们公司烦人
|
|
86
@creanme 这个我就可以理解，如果是测试组整体这么要求，我是可以理解并且乐意给她讲解的。
|
 |
87
开发周期长、时间充裕的情况下, 测试这么做没问题.
反之, 你们需要的可能是黑盒测试, 测试人员不需要关心代码, 只需要关心操作导致的程序行为是否正确. 国内非金融业务应该大部分都是这鸟样, 程序能跑就行... 最恶心的就是 开发周期短 + 禅道要填完整的 issue 单(基本相当于把白盒测试要做的要写都都丢给开发写, 一整页下来都是必填项), 只能对这种环境说, 吖屎啦你! |
 |
walkerzmcOct 26, 2022
88
神仙测试，建议珍惜，错过了有可能这辈子都遇不到这么好的了。再说回来，如果你觉得麻烦，公司规模不管如何都会觉得没必要。
|
 |
vzhzhqOct 26, 2022
89
这不挺好的嘛，我们公司有个这样负责的测试，线上出了 bug 她都能直接回复，还能告诉我怎么改
|
 |
F281M6Dh8DXpD1g2Oct 26, 2022
90
ticket 写清楚让她自己看去
|
 |
AixtuzOct 26, 2022
91
工作时间出点力，好过休息时被抓壮丁啊...
|
 |
kltt22Oct 26, 2022
92
要先问清楚，是白盒测试还是黑盒测试。如果是白盒，丢源码过去，如果是黑盒，拒绝回答，理由就是保证测试工作的顺利进行。
|
 |
SeanfuckOct 26, 2022
93
估计这测试不漂亮，否则不会烦她
|
 |
humpyOct 26, 2022
94
好测试啊，她应该当测试组长的。我们这边也是这样，测试能看懂代码，提测之后人家直接 review 代码...真能发现不少代码里的逻辑漏洞。
|
 |
xiangpengOct 26, 2022
95
作为一个从做项目转到测试的人来说两句，我是做业务测试，也不分黑盒白盒，就一个要求，确保线上不出现 Bug ，如果就做流程测试，把所有流程分支都测试到了，一样会出现 Bug ，因为线上数据各种各样，测试环境不可能完全复盖（起码我们的是），为了不出或者少出线上 Bug ，只能去通过业务逻辑理解去找可能出现的问题点再制造对应数据去验证，久而久之就是测试比研发更熟悉业务（研发只负责个别微服务，测试要测所有业务，业务之间的关联研发可能考虑不到），OP 说的这种测试应该是因为对产品不够熟悉导致了问的比较多，一旦对产品足够熟悉，日常提提建议，怼怼研发家常便饭，同样也能很大程度上降低线上 Bug 的出现，“先培养，再利用”，属于先苦后甜的类型吧，个人经验，供参考。
|
 |
nooneloveOct 26, 2022
96
真的可以把她的简历推给上面想招这样测试的人，他们找到了想要的人，你提升了效率，两全其美...
|
 |
PythonYXYOct 26, 2022
97
建议少写 BUG ，这样就不会被烦了（
|
 |
98
她其实是在学，学会了就转后端了
|
 |
99
说明你们裸奔开发非常好，值得成为业界标准。
不走流程非常快，不总结错误省时间，遇山开山，水来土掩。顺其自然大法好。 |
 |
tf2Oct 26, 2022
100
要么保证没 bug ，要么就耐心把怎么改的告诉 TA 呗。
|
Select Language