这是一个创建于 766 天前的主题，其中的信息可能已经有所发展或是发生改变。
是这样子的，这个测试有个毛病，真的太烦人了。你每次改完一个 BUG 让她去验证一下，她都要问你，这个 BUG 是怎么改的，逻辑是啥？是加了个判断吗？总之就是要知道后端改这个 BUG 的代码逻辑。
然后就是遇到有洗数据的 SQL 时，非要我们把 SQL 发给她看，还说她需要知道 SQL 是怎么写的，好进行测试。
这两种行为，公司所有的测试就她一个人有，跟她说，她还反驳说，其他人怎么样她不管。
第 1 条附言 · 2022-10-26 16:33:05 +08:00
我说明一下，如果是整个测试组都有这个要求，那我是非常乐意给她说这些的。现在是测试组长都没有提过这个要求，就她一个刚转正的提了这个要求。我觉得如果真有这个需求，可以先反馈给她的组长。
 |
1
28Sv0ngQfIE7Yloe 2022-10-26 14:36:15 +08:00  156
突然感觉 ta 挺负责的
|
 |
2
matthewzhong 2022-10-26 14:38:30 +08:00 2
建议配合
|
 |
3
optional 2022-10-26 14:38:31 +08:00 via iPhone 44
这是神仙测试。请珍惜吧，直接把 pr/mr 加上她，一个负责的 reviewer 啊
|
 |
4
kusiruu 2022-10-26 14:38:50 +08:00 3
她在引起你的注意
|
 |
5
baoyinlei 2022-10-26 14:38:53 +08:00
挺好的，很负责啊。
|
|
6
optional 2022-10-26 14:39:13 +08:00 via iPhone 1
真想挖过来
|
 |
7
Jooooooooo 2022-10-26 14:40:49 +08:00
正确的测试方法.
|
 |
8
xianghaolin 2022-10-26 14:40:57 +08:00
这样的测试，你还不要？
|
 |
9
itechnology OP |
 |
10
lessMonologue 2022-10-26 14:41:39 +08:00 2
正确的，只有她；错误的，除了她。
|
 |
11
xiaoming1992 2022-10-26 14:41:47 +08:00 1
@kusiruu 女人，你在玩火 [狗头]
|
 |
12
guaguaguaxia1 2022-10-26 14:41:53 +08:00 2
这么厉害负责的测试你居然嫌弃，我觉得是你的问题
|
 |
13
eason1874 2022-10-26 14:42:18 +08:00
没用 git 吗，每次 commit 记录写清楚当次更改就行了，感觉没啥毛病
|
 |
14
ql562482472 2022-10-26 14:42:21 +08:00 10
对于测试来说，这是个黑盒
你操作过黑盒就知道黑盒多恶心了 对着黑盒干活有多累 |
 |
15
fenglangjuxu 2022-10-26 14:44:28 +08:00 6
这个我觉得没毛病啊
如果真的是很专业的测试 知道你的实现思路 知道你的表结构 然后人家要知道 bug 的原因 也算合理 |
 |
16
x1kong 2022-10-26 14:44:54 +08:00
这是个好测试（至少从她的测试行为上看）。如果她只是给点两下就说测试通过了，那才是对交付质量的不负责。
|
|
17
itechnology OP @ql562482472 这个我理解，但关键是我们公司不要求黑盒测试呀，也不要求白盒测试。只要普通的测试就可以了。
|
 |
18
jujusama 2022-10-26 14:46:51 +08:00
神仙测试
|
|
19
optional 2022-10-26 14:47:45 +08:00 via iPhone
@itechnology 不懂珍惜啊，可以透露下什么 title 不，senior ？
|
 |
20
Vindroid 2022-10-26 14:49:10 +08:00
这个测试懂程序？可以理解为负责，也可以理解为她想多学点开发的内容。话说你们把 issue 转为已解决时，都不贴 gerrit 的解决链接和描述问题点以及解决办法的吗？
|
 |
21
luckycoding 2022-10-26 14:49:19 +08:00 31
人型小黄鸭，建议好好讲，即锻炼了表达能力，又落得个好名声。
|
 |
22
777777 2022-10-26 14:50:44 +08:00
我们没有测试，出问题了然后背锅
|
 |
23
bk201 2022-10-26 14:51:30 +08:00
这不就是她的职责吗？你如果嫌麻烦，你和领导说你自己保证自己的质量，不需要测试得了
|
 |
24
learningman 2022-10-26 14:51:40 +08:00
正确的，建议 reviewer 直接加上她
|
|
25
itechnology OP @Vindroid 她不懂后端语言的。我们后端把 issue 转为已解决时不需要贴 gerrit 的解决链接和描述问题点以及解决办法。小公司没有这么规范，都是解决了，git 的 commit 写一下解决了什么 BUG 就行了。
|
 |
26
buyan3303 2022-10-26 14:51:57 +08:00
如果测试真做到这样，并有做非常详细的记录，就珍惜她吧，
有时候你改了一个 iPhone7 下 safari 适配 BUG ，但是可能在某度浏览器下，又没有这个 BUG ， 如果出了一个大的事故，可能测试的记录，能加速定位 BUG 。 |
 |
27
amiee0599 2022-10-26 14:53:27 +08:00
总比让你带着 bug 上线好
|
 |
28
mikuazusa 2022-10-26 14:54:43 +08:00
神仙测试，不出问题你嫌弃，真出大事了你们会后悔没好好珍惜的
如果她真的能找出很多 bug ，而且只有她一个这么突出，预测后面她会很快晋升 |
 |
29
weizhen199 2022-10-26 14:58:20 +08:00
@itechnology 那你可以把解决问题的过程解释的越详细复杂[del]折磨[/del]咯，让她 handle 不了咯
|
 |
30
lululau 2022-10-26 14:58:31 +08:00 1
如果每个问题都需要开发向测试解释一遍前后逻辑，这也太没效率了。。。两个方法，1: 协商只有符合某些条件的问题才需要这个过程； 2: 让测试自己去看 git 提交记录
|
 |
31
infun 2022-10-26 14:59:40 +08:00
要么把她简历给我？
|
 |
32
gxm44 2022-10-26 15:02:23 +08:00
很不错的测试
|
 |
34
jdandelion573 2022-10-26 15:02:54 +08:00
把联系方式晒出来, 被挖走就不烦人了.
|
|
35
itechnology OP @lululau 我就是觉得太没效率了，解决一个 BUG 都要花时间跟她解释一下逻辑，有时候跟她说，她还不一定听得懂，然后又要换一种方式跟她说。
|
 |
36
AslanFong 2022-10-26 15:06:21 +08:00
你们公司不配她惹
|
 |
37
renhou 2022-10-26 15:09:07 +08:00 1
虽然她很负责，但是这么做就会增加别人的负担
公司可以找一个懂那些东西并且话少的测试，这明显对效率至上的公司更有利 |
 |
38
zhuangpipi 2022-10-26 15:09:12 +08:00
这种情况需要她的能力足够强，能够听懂你说的逻辑问题和解决点，否则算是负担了。
|
 |
39
lazyfighter 2022-10-26 15:11:17 +08:00
有没有想过是你们的流程不合理的问题， 不是测试的问题
|
 |
40
lx0758 2022-10-26 15:11:28 +08:00
让她做黑盒测试, 不要老想着白盒测试
|
 |
41
zhout 2022-10-26 15:11:33 +08:00
因为你滥竽充数
|
 |
42
ccyu220 2022-10-26 15:20:56 +08:00 1
想到一句话，天鹅在鸭群
|
 |
43
offswitch 2022-10-26 15:27:46 +08:00 2
@itechnology 这个测试很不错，不过可能呆在你们公司的话，这样会废了，如果你们公司不能给她一个比较好的培养环境，跟这个测试说一下，让她联系上面的这些人，去一个更好的环境培养。
|
 |
44
xuxu5112 2022-10-26 15:29:42 +08:00
git 权限给她
|
 |
45
cominghome 2022-10-26 15:31:43 +08:00 1
是不是长得不太行？不然这难道不是两全其美的好事吗
|
 |
46
Dlin 2022-10-26 15:33:08 +08:00 42
我知道为什么你讨厌她，因为她不够年轻漂亮。
|
 |
47
ylls 2022-10-26 15:34:08 +08:00
如果不管什么 bug 都要解释一遍的话 确实有点浪费时间 有时候改一个 bug 10 分钟 可能解释得半小时 如果还是那种解释一遍听不懂那种 那更费时间了
|
 |
48
shixuedela 2022-10-26 15:34:25 +08:00 2
你抱怨她询问你解决 BUG 的方式,不如想着怎么减少 BUG.这样不是更好吗?
是因为之前其他人不负责任,就觉得这个测试吹毛求疵吗? 做好自己份内的事. |
 |
50
NineNan 2022-10-26 15:35:38 +08:00
很负责任的测试
|
 |
51
emric 2022-10-26 15:40:43 +08:00
可以发一下她联系方式... 我这边还真的招...
|
 |
52
thulof 2022-10-26 15:41:18 +08:00
有联系方式吗？
|
 |
53
adrianXu 2022-10-26 15:43:31 +08:00
我非常喜欢这样的测试
|
 |
54
wingor2015 2022-10-26 15:44:03 +08:00 1
她想做测试工程师，但是很多公司只需要一个测试，不需要工程师
|
 |
55
1000copy 2022-10-26 15:44:04 +08:00
你不讲就行了啊。不会是欲拒还迎？
|
 |
56
Pichai 2022-10-26 15:47:23 +08:00
这个测试确实负责，但这种负责对于双方来说都是需要消耗大量精力的。
建议和她进行沟通，达成一个一致的目的。每次修改完 bug 让验证的时候，在当前 bug 的备注信息中尽量使用一句话给对方讲清楚如何修改好了这个 bug 。 |
 |
57
Innovatino 2022-10-26 15:47:25 +08:00
可以跟他说，临下班的时候找半小时统一讲，上班的时候不能打断思路
不过我觉得这样的测试还挺好的，总比瞎测一通强 |
 |
58
lzgshsj 2022-10-26 15:48:12 +08:00
你嫌问的烦，那就直接把你改动的逻辑说明写好，在她问之前先发给她。你把解释当成写文档，写文档你总不至于嫌烦吧。
|
 |
59
justfindu 2022-10-26 15:50:06 +08:00
理论上她知道逻辑能够更好的测试. 不然就需要摸摸摸摸摸摸.....
|
 |
60
corningsun 2022-10-26 15:51:31 +08:00 1
如果测试理解能力正常，我会很乐意跟他分享 bug 的原因和修复的逻辑。
花费时间长只有两种可能，一测试智商有问题，二我智商也有问题，表达不清楚。 |
 |
61
joyyu 2022-10-26 15:51:32 +08:00
可以让她学学后端语言，美其名曰拓宽自己的能力。
她不是想知道你修 bug 的逻辑么，到时候直接甩给她提交的 commit ，让她亲手来给你 review 代码！ |
 |
62
wineast 2022-10-26 15:51:56 +08:00
有联系方式么？楼主在哪里？
|
 |
63
yuhuanxi 2022-10-26 15:52:03 +08:00
真负责的测试，而我遇到的很多测试，都很随意，有时候我还主动跟对方说哪里出的问题，改了哪里。遇到楼主这种测试，好好珍惜吧，时间久了，你的沟通能力、语言表达能力都能锻炼出来。
|
 |
64
hnbcinfo 2022-10-26 15:53:34 +08:00
你可以在改完 BUG 提交给她的时候，把她想要的写成文档都给她。甚至能帮不养成一个好习惯。作为一个局外人，我觉得挺好的。
|
 |
65
mockRan 2022-10-26 15:55:17 +08:00
很负责的测试，你觉得很烦会不会是因为流程不够完善呢。像我们开发的时候时候，评审，方案落地都会带上测试一起让他们知道大体的流程。测试阶段，测试会有测试用例评审，测试提出用例，开发来评判用例对不对，能不能覆盖到修改点，流程完善的情况下，对双方都好。
什么不都跟测试说，只丢给需求给测试，有让测试背锅的嫌疑。。。 |
 |
66
dqzcwxb 2022-10-26 15:55:58 +08:00
身在福中不知福
|
 |
67
yueban5521 2022-10-26 15:56:04 +08:00
时间很紧张的话，这个东西解释起来很烦的，还有一个问题就是如果没有语言基础的话，解释起来她也似是而非的，如果按照开发的思路来测试，开发的自己验证就够了，有自己的思路才能验证出更多的问题；
|
 |
68
unco020511 2022-10-26 16:00:13 +08:00
这是正常流程啊,我们团队的 mr 入库必须给测试提供: 改动逻辑 /范围 /和影响面,你想想,如果测试不知道你这次的改动逻辑和影响面,那他怎么知道你这次的改动他要验证哪些内容(做 A 功能很有可能影响原有 B 功能),不然把整个应用全部都验证一遍吗
|
 |
69
redford42 2022-10-26 16:01:22 +08:00 1
改 bug 都要走 jira 吧？
jira 上把修改逻辑写好不就完了 |
 |
70
yao177 2022-10-26 16:01:34 +08:00
我们 pr 都会带上 ta review ，这是真的神仙测试啊
|
 |
71
Vegetable 2022-10-26 16:02:25 +08:00
很难认可你的想法
|
|
72
unco020511 2022-10-26 16:02:28 +08:00
遇到这种测试真要珍惜,出过一次线上事故就懂了
|
 |
73
fuckaholic 2022-10-26 16:04:38 +08:00
她，真的很好
|
 |
74
bytesfold 2022-10-26 16:06:14 +08:00
很负责
|
 |
75
acerest 2022-10-26 16:06:35 +08:00
简历给我，内推费给你，谢谢。
|
 |
76
tkHello 2022-10-26 16:07:46 +08:00
不错的摸鱼条件 珍惜
|
 |
77
MoYi123 2022-10-26 16:07:56 +08:00
给懂的讲和不懂的讲是两回事, 不懂的你讲之前是不是还要给他普及一下基础概念, 非常麻烦的.
|
 |
78
kindom 2022-10-26 16:09:14 +08:00
op 取暖失敗
|
 |
79
ymlluo 2022-10-26 16:11:24 +08:00
请珍惜
|
 |
80
ztxcccc 2022-10-26 16:11:32 +08:00
你们提交代码不带 BUG 单号？完全可以让她直接去看变更记录
|
 |
81
creanme 2022-10-26 16:12:15 +08:00
我们测试也会问什么原因，怎么解决的，似乎是他们领导强制要求记录的。
|
 |
82
kevinlexming 2022-10-26 16:12:49 +08:00
我觉得主要还是长得不乖
|
 |
83
terence4444 2022-10-26 16:22:00 +08:00 via iPhone
直接让她看 commit 不就行了吗
|
 |
84
catsoul 2022-10-26 16:24:55 +08:00
如果可以的话，建议批量引进这样的测试
|
 |
85
Dbin 2022-10-26 16:28:45 +08:00
简历发出来 让他来我们公司烦人
|
|
86
itechnology OP @creanme 这个我就可以理解，如果是测试组整体这么要求，我是可以理解并且乐意给她讲解的。
|
 |
87
wu67 2022-10-26 16:32:04 +08:00 2
开发周期长、时间充裕的情况下, 测试这么做没问题.
反之, 你们需要的可能是黑盒测试, 测试人员不需要关心代码, 只需要关心操作导致的程序行为是否正确. 国内非金融业务应该大部分都是这鸟样, 程序能跑就行... 最恶心的就是 开发周期短 + 禅道要填完整的 issue 单(基本相当于把白盒测试要做的要写都都丢给开发写, 一整页下来都是必填项), 只能对这种环境说, 吖屎啦你! |
 |
88
walkerzmc 2022-10-26 16:32:46 +08:00
神仙测试，建议珍惜，错过了有可能这辈子都遇不到这么好的了。再说回来，如果你觉得麻烦，公司规模不管如何都会觉得没必要。
|
 |
89
vzhzhq 2022-10-26 16:36:29 +08:00
这不挺好的嘛，我们公司有个这样负责的测试，线上出了 bug 她都能直接回复，还能告诉我怎么改
|
 |
90
liprais 2022-10-26 16:37:00 +08:00
ticket 写清楚让她自己看去
|
 |
91
Aixtuz 2022-10-26 16:44:35 +08:00
工作时间出点力，好过休息时被抓壮丁啊...
|
 |
92
kltt22 2022-10-26 16:48:01 +08:00
要先问清楚，是白盒测试还是黑盒测试。如果是白盒，丢源码过去，如果是黑盒，拒绝回答，理由就是保证测试工作的顺利进行。
|
 |
93
Seanfuck 2022-10-26 16:53:59 +08:00
估计这测试不漂亮，否则不会烦她
|
 |
94
humpy 2022-10-26 16:56:33 +08:00
好测试啊，她应该当测试组长的。我们这边也是这样，测试能看懂代码，提测之后人家直接 review 代码...真能发现不少代码里的逻辑漏洞。
|
 |
95
xiangpeng 2022-10-26 16:56:36 +08:00
作为一个从做项目转到测试的人来说两句，我是做业务测试，也不分黑盒白盒，就一个要求，确保线上不出现 Bug ，如果就做流程测试，把所有流程分支都测试到了，一样会出现 Bug ，因为线上数据各种各样，测试环境不可能完全复盖（起码我们的是），为了不出或者少出线上 Bug ，只能去通过业务逻辑理解去找可能出现的问题点再制造对应数据去验证，久而久之就是测试比研发更熟悉业务（研发只负责个别微服务，测试要测所有业务，业务之间的关联研发可能考虑不到），OP 说的这种测试应该是因为对产品不够熟悉导致了问的比较多，一旦对产品足够熟悉，日常提提建议，怼怼研发家常便饭，同样也能很大程度上降低线上 Bug 的出现，“先培养，再利用”，属于先苦后甜的类型吧，个人经验，供参考。
|
 |
96
noonelove 2022-10-26 16:57:25 +08:00
真的可以把她的简历推给上面想招这样测试的人，他们找到了想要的人，你提升了效率，两全其美...
|
 |
97
PythonYXY 2022-10-26 16:58:07 +08:00
建议少写 BUG ，这样就不会被烦了（
|
 |
98
darknoll 2022-10-26 17:00:49 +08:00 3
她其实是在学，学会了就转后端了
|
 |
99
yufeng0681 2022-10-26 17:02:14 +08:00 1
说明你们裸奔开发非常好，值得成为业界标准。
不走流程非常快，不总结错误省时间，遇山开山，水来土掩。顺其自然大法好。 |
 |
100
lambdaq 2022-10-26 17:03:15 +08:00
要么保证没 bug ，要么就耐心把怎么改的告诉 TA 呗。
|
Select Language