这是一个创建于 611 天前的主题，其中的信息可能已经有所发展或是发生改变。
简单说就是测试的 kpi 是找出开发更多的 bug,开发的 kpi 就是避免 bug 。 但实际上找 bug 相对更容易，有时候太吹毛求疵了。但是二者来说测试更主动，就像裁判员，想找问题总能找的到。 敢和产品 battle ，但是不能和测试 battle 万一不爽了真就拿放大镜测。
测试地位也比产品高，测一些功能点遇到自己不理解的设计就会直接问开发和产品为啥这么设计，给产品提优化。当然这种是公司氛围支持的，搞对立，抓 bug 率搞榜单。
但总得来说，测试可以用 bug 拿捏开发，开发没有什么能拿捏测试的，你说代码写的好点自测好点没问题就行了，但你说了不算。可提可不提的东西就好像寻衅滋事口袋一样，心情好就算了，心情不好就提了。 如果迭代测试下来没发现什么 bug ，那就得找点 bug ，反之会松一点。
以前呆过地方，基本和测试也就平级关系吧，有问题提个单子改一下就是了。这边被提个单子感觉就很严重，另外就是开发在提测前要反复自测，一天开发的工作量可能要花两天来自测，以防有 bug 。
 |
1
xwayway 2023-03-24 08:57:11 +08:00  11
哈哈，，，测试和开发明明就是相互协同的关系，怎么搞得像阶级敌人一样
|
 |
2
tedzhou1221 2023-03-24 08:59:52 +08:00 2
说明他懂业务。你们不够他熟。
|
 |
3
lifesimple OP @xwayway 就是这个感觉，但是测试可以拿捏开发，是大爷
|
 |
4
zcjfesky 2023-03-24 09:01:29 +08:00 via Android
金融类公司的合规风控也差不多是这个性质
|
 |
5
god7d 2023-03-24 09:03:31 +08:00 6
有的公司测试地位碾压开发，连产品都得听测试的，比如：
测试：喂，这是一个 bug 开发：不是 bug ，产品就是这么设计的 测试：产品怎么能这么设计呢……（过了一会儿）产品改设计了，单子提给你了 对于老板来说，非常乐于看见这种情形，因为这公司产品只是个客户需求转述专员，开发就是纯工具人，保证软件没问题才是第一要务，一般常见于 toB 的软件行业 |
 |
6
yyysuo 2023-03-24 09:03:54 +08:00 1
那要看测试人员的水平了，如果测试人员水平确实比较高，那产品肯定质量也高。当然，产品是否受欢迎能成功，有时候跟质量也没什么关系。
|
 |
7
lishoujun 2023-03-24 09:04:52 +08:00 13
测试岗来尝试回答。
测试岗通常是不会创造业务价值的，在多数公司都是成本部门。 如果一个公司测试地位很高，排除办公室政治因素外，我能想到的有两种可能： 1 、这个公司的测试组已经完成了测试执行到质量保障（含用户体验）的过度，从老板的角度看，测试和自己的站位一致，所以会更加相信测试组的评价。 2 、历史上，出现过严重或者高频的线上问题，导致资损，因此质量保障的地位被提高了。 无意冒犯，纠正你的第一句话，开发的 kpi 不应是避免 bug ，而是对产品需求进行落地。 无法落地的产品，bug 再少也枉然。 如果你的老板对你的 kpi 过于偏向 bug ，你可以适当向上反馈一下，平衡项目产出和缺陷的比重。 |
 |
8
yaphets666 2023-03-24 09:04:59 +08:00 1
程序在测试阶段有 bug ，这是天经地义的事
|
 |
9
8355 2023-03-24 09:06:47 +08:00 4
测试还能拿捏开发？
如果按照你的说法测试阶段 bug 你测出来是你的岗位价值，测不出来不才是你有问题吗？ 其次影响开发 kpi ？那上生产有 bug 是不是全是测试的责任毕竟是你没测出来？ 开发写的代码没有 bug 还会需要测试吗？ 开发假如把你测试的时间用来写单元测试或者自己开发自动化测试脚本做不到的嘛？ 到底谁拿捏谁，到底谁给谁提供工作岗位你再想想？ |
 |
10
NessajCN 2023-03-24 09:06:48 +08:00 1
说明你水平不够
只要你别写一堆 bug, 或者你的 bug 都没法靠一般测试流程测出来，那测试拿什么拿捏你呢 说到底菜鸡就该被拿捏 我做开发时候测试都跑过来跟我商量让我故意写点无关痛痒的小 bug 好让他们别看起来那么无所事事， 这样谁拿捏谁呢 |
 |
11
pre 2023-03-24 09:07:22 +08:00
我们今年共 4 个版本，每个版本迭代，每个人 BUG<=12 为 A , 13-15 为 B ，15 以上为 C ，呵呵
|
 |
12
1t1y1ILnW0x5nt47 2023-03-24 09:10:09 +08:00 4
大家都是给资本家打工,何必较真呢
|
|
13
god7d 2023-03-24 09:11:45 +08:00 1
@pre 对于很多按部就班的开发任务来说，老板要的是速度，所以 bug 少可以加快开发周期，尽快部署，我是这么认为的，这种行业我觉得没有意思
|
 |
14
jjx 2023-03-24 09:26:34 +08:00 2
开发自己做一个功能, 自己用不了几次
测试可能几十次,上百次的用, 所以, 有时还是要尊重测试 |
 |
15
runinhard 2023-03-24 09:35:00 +08:00 1
说到底，写出了 bug 才会被别人抓到，有本事就不写 bug 。
至于是 bug 还是 feature ，本身就应该有严格的定义和规范。测试可以利用这个漏洞，开发和产品难道不能利用？ 有得公司互相卷才能把事情做好，有得公司不卷能把事做得更好。 不合适罢了 |
 |
16
dd991 2023-03-24 09:41:38 +08:00 1
说明你们技术太水了，连个测试都搞不定
|
|
17
pre 2023-03-24 09:47:00 +08:00
@god7d 版本是固定的，一个版本迭代几个月时间，都是业务模块，复杂度耦合性还很高，一两个任务做下来不仔细点就超了。现在就各种卷，对着 checklist 一条条过，还不能完全保证没有 BUG ，毕竟测试现在是大爷
|
 |
18
faithid 2023-03-24 10:03:11 +08:00
有没有待过运维地位极高的公司？处处卡你脖子，开发给运维解释业务。
|
 |
19
Yeen 2023-03-24 10:19:52 +08:00
你把测试换个名字叫做 QA ，心态会瞬间提升
|
 |
20
startisan 2023-03-24 10:23:51 +08:00
这样搞，如果功能上线后出了问题，就是测试的锅了吧，产品和开发都会说测试没测充分。。
|
|
21
faithid 2023-03-24 10:24:02 +08:00
有没有待过运维地位极高的公司？处处卡你脖子，开发给运维解释业务。
|
 |
22
ah64zzpk 2023-03-24 10:24:35 +08:00
简单说就是测试的 kpi 是找出开发更多的 bug,开发的 kpi 就是避免 bug
---这个 kpi 定的本来就有问题了。测试和开发都有一个相同的目的是交付能够符合需求的软件。 |
 |
23
littlecreek 2023-03-24 10:49:22 +08:00 2
测试地位高一般也是人家老大打出来的威望, 他们 team 可能对业务更精通, 更贴近用户, 说话有理有据, 开发不得不服.
我之前也带过测试地位很高的公司, 测试出来 严重 bug 太多, 测试部门直接提测不通过, 开发老大战战兢兢. 但是说实话我跟他们打交道的时候感觉他们提的东西绝大部分我是心服口服的, 除了极少数新员工为了快点出成绩提一些吹毛求疵的东西, 大部分测试员工提的东西都没问题. 然而那是以前软件质量精益求精的年代, 现在的潮流是快速试错, 测试的地位就要让位于快速出产品了, 时代变了. |
 |
24
47d7tEUBp521E8fJ 2023-03-24 10:50:20 +08:00
抓 bug 率搞榜单不合理，bug 的多少跟开发也有关系。碰到细心的开发可能一个很难的需求可能就一两个 bug 。另一个开发可能就天天写 bug ，那永远都是接天天写 bug 的测试更优秀？
|
 |
25
levelworm 2023-03-24 10:53:51 +08:00 via Android
需要有个总抓的人平衡
|
 |
26
leon0918 2023-03-24 11:15:14 +08:00
你是不是在涂鸦
|
 |
27
optional 2023-03-24 11:26:14 +08:00 via iPhone
这个简单，开发前要求产品必须完善 prd 和 testcase 这个需求评审必须拉上测试，超出 prd 和 testcase 的一律不认，中途改了 prd 和 case 的必须重新评审重新估时
|
 |
28
perfectlife 2023-03-24 11:26:15 +08:00
@faithid 运维毕竟拥有的权限比较高，然后工作中也不需要求人开权限啥的，选择性多，一句 安全隐患 /稳定 就能抵挡好多要求， 另外好多开发 内外网 ip 都分不清，一个运维往往对公司内几十个研发，所以运维就一视同仁对待开发，死道友不死贫道
|
 |
29
c8c 2023-03-24 11:31:38 +08:00
测试的 KPI 不应该是找到多少个 bug ， 而应该是从 用户的角度出发 ，和 开发一起 交付符合用户需求，有一定程度质量 的功能
做开发就难免会出现 bug ， 这是正常的，就像常在河边走，难免会湿鞋 一样。 |
 |
30
jwen 2023-03-24 11:48:15 +08:00
出了线上问题，测试接锅不 ？
|
 |
31
fuzzsh 2023-03-24 11:49:17 +08:00 via Android
U can U do
|
 |
32
KnightYui 2023-03-24 11:50:54 +08:00
同样在这样的公司，虽然很不爽，但是不得不承认，产品质量确实会好很多。
|
 |
33
cue 2023-03-24 11:54:42 +08:00
在我们公司 测试＞研发＞＞＞产品＞运营
|
 |
34
qooweds 2023-03-24 11:58:45 +08:00
这不是开发和测试地位的问题,是产品定位的问题,一般跟行业有关
产品不能允许出现质量问题,可以允许一天开发的工作量要两天的自测,说明老板认为产品质量比开发效率重要很多,愿意付出这个成本 OP 这个应该是不是普通的 web 项目吧?普通的 web 项目不可能在测试中投入这么多时间 |
 |
35
litguy 2023-03-24 12:32:23 +08:00
我作分布式存储的
测试比研发多 测试架构师跟我 BB 的时候 我告诉他，设计就这样了 如果你觉得需要改 我懒得和你讨论 如果 2 年后公司还在 咱俩再讨论这个问题 别啥都被人 push |
 |
36
zhaokun 2023-03-24 13:08:48 +08:00
没有谁拿捏谁，就是一份工作，可能是有些人沟通方式不友好，别放大沟通方式
|
 |
37
AloneHero 2023-03-24 13:12:13 +08:00 via Android 3
楼上说技术水的真是搞笑，并不是技术问题，这种情况最大的问题就是测试遇到问题会能提 bug 的都提，开发又会因为一些似是而非的 bug 一直和测试争论，开发之间本来能顺手帮别人修改的问题也会严格讨论谁来修改，衍生的问题很多，整体下来的结果就是整个团队氛围极度紧张，合作效率非常低下，待起来很恶心
|
 |
38
dandycheung 2023-03-24 13:14:57 +08:00 via Android
只要你想，开发并不是没有反击的力量。面相测试编程，给他埋几个坑，证明他测不出来高水平的问题其实也不是难事。
|
 |
39
fantathat 2023-03-24 13:23:56 +08:00 via iPhone
因为这公司产品只是个客户需求转述专员，开发就是纯工具人，保证软件没问题才是第一要务，一般常见于 toB 的软件行业
|
|
40
fantathat 2023-03-24 13:26:20 +08:00 via iPhone
空子很大，漏洞自然也很大，为什么空子这么大呢？你自己好好想想
|
|
41
fantathat 2023-03-24 13:27:10 +08:00 via iPhone
故意放出来的 bug ，然后赶时间缩短了工期而已
|
|
42
fantathat 2023-03-24 13:29:36 +08:00 via iPhone
跟测试没关系，跟你们公司的管理有关，跟你们客户有关系
|
 |
43
msg7086 2023-03-24 13:31:38 +08:00
可提可不提的 bug 是什么东西？
|
 |
44
IvanLi127 2023-03-24 13:35:23 +08:00 via Android
我写个剧本
开发组怕被测出 bug ，开始自测。 自测又有点测不出来，开始互相测试别人的功能。 天天互相测试，发现效率不太好，就选了人出来专门测试。 然后就出现了开发组内的测试人员。 然后，测试部门吃灰，hr 开了测试部门，调整组织架构，重新划分部门和 kpi 。 这是一个只有研发扣工资，hr 刷奖金的世界。 |
 |
45
RubyJack 2023-03-24 14:06:45 +08:00
线上问题，测试没覆盖到的是测试责任，覆盖到了还出问题也是测试责任
|
 |
46
lpt0 2023-03-24 14:14:13 +08:00 via Android
不是华为吧
|
 |
47
flyingghost 2023-03-24 14:32:59 +08:00 1
1 ，测试测 bug 是本职工作。能被测试测出 bug 的开发，只能说活该水平不够。
2 ，开发应该带着感恩的心。我司线上生产事故测试必背大锅，比开发比例还大。测试是开发的守门员，没有测试，那只好开发自己背锅。让开发自己选。 3 ，需求层面打不过测试的，只能说开发不熟悉业务。开发天然是既了解业务又洞悉本质的岗位，正常公司是产品引导、测试守门，但没有任何人能在宏观或微观层面打得过开发。 4 ，如果由于理解偏差导致的“bug”，请修改项目组 bug 定义和分类。开发常见几种觉得委屈的需求 bug： 一种是讲的不够细，每个人有每个人的理解方式。大锅扣给产品，请描述好需求。开发的责任在于：讲得不够细就多问，又闷又自作聪明的开发太多，又谨慎又多嘴好问的开发太少。 另一种是开发犯了一些常识性的错误。例如产品说这里要有个密码框，开发直接文本框明文显示了，测试认为应该掩码不能明示。如果一个 bug 是公认的常识，那不理解常识的一般是经验不足，请补。 5 ，开发不私接小需求。小需求、小变更要同步，大变更要重走完整流程。这个也是很常见的委屈“bug”来源。 6 ，某些测试可以担当 QA 角色，对于设计、体验、技术方案都能提出见解。挺合理。团队就应该人人可发言，只要有道理，即可采纳。人家水平高啊。但在一些 UI/UX 、运营等非技术角度，开发缺位是常态。太钻技术了，太少抬头看宏观。我是期望团队内所有人都应该专精本职工作的基础上具有一定跨界能力，尤其产品本身的理解，和用户角度的理解。这方面产品容易缺的是技术理解，开发容易缺的是产品思路，反而测试较容易做到期望的“一专多能”。 总之，综合来说，开发真的是天然最强势角色，至少是最容易达到。被打压出普遍委屈和不满，只能说明。。。项目经理 /团队 Leader 的锅最大。。。 |
 |
48
wintersun 2023-03-24 14:59:22 +08:00
我给自己团队的测试是这样定位的： 半个产品经理！
但是，并不代表 TA 可以高高在上的“指挥”其他人。 一个软件产品开发迭代出来，能提供终端用户价值，要在 时间、质量、成本上做出平衡，更要在运营上花大力气。 所以，这是一个如何平衡的管理艺术……偏颇任何一方都可能翻船。 记住一点，任何方面，从 95 分做到 100 分，所需要的成本可能翻一倍。 |
 |
49
chenPiMeiHaoChi 2023-03-24 15:02:04 +08:00
绝了，感情楼上这些说水平不够的自己没 BUG 是吧，个个月入 5 万的精英？
|
 |
50
BQsummer 2023-03-24 15:08:50 +08:00
1. "这边被提个单子感觉就很严重，另外就是开发在提测前要反复自测，一天开发的工作量可能要花两天来自测，以防有 bug 。" 这不是应该的吗.
2. 测试有权利提单子, 开发也有权利拒绝不合理的单子. 3. 理论上测试是生产 bug 的第一责任人,严格一点很正常, 如果因为提 bug 单导致氛围不对, 那是公司的问题. 4. 我们这种基础服务部门, 没有产品, 测试会有部分产品的角色. |
 |
51
RainCats 2023-03-24 15:22:58 +08:00
我现所在公司就是啊，开发时间紧，还是结合自研的低代码平台来搞，也没需求评审的。
反正就是开盲盒呗，绩效全看测试激活次数，不看理由 |
 |
52
zhaoxiaolei 2023-03-24 15:27:42 +08:00
停下来总体感觉你们做的东西总体质量不高，然后公司也没有一个统一的标准线，以及领导非常不客观，导致了开发被测试拿捏的奇怪情况。建议建立一个统一的标准，一个缺陷需不需要修复应该是一个客观的问题，不是测试主观上决定的。
|
 |
53
seres 2023-03-24 15:33:01 +08:00
我能想到的是金融，军工相关的。。
|
 |
54
zong400 2023-03-24 15:54:20 +08:00
你想拿捏测试？搞个隐蔽 bug ，上线才爆发的，呵呵
|
 |
55
zhaol 2023-03-24 15:54:31 +08:00
@flyingghost #47 逆天，按你的第一条，这世界有水平够的开发吗？
|
 |
56
rcchen123 2023-03-24 15:56:13 +08:00 1
权力（地位）与责任是对等的。
我司项目的上线日期等重大时间点都是测试安排、盯着、督促和保证的。 其它人只要把这些活儿接过来，也能有很大话语权。 |
 |
57
cloud107202 2023-03-24 16:28:40 +08:00
金融科技公司大多都这样，可能上位的老大是个测试出身或者喜欢玩政治。
这种人是乐于看到下面互相撕的，老板也喜欢 |
 |
58
salmon5 2023-03-24 16:29:01 +08:00 1
欲戴王冠，必承其重
这没什么好说的，看谁对结果负责 |
 |
59
swordfairy 2023-03-24 16:38:39 +08:00
@zong400 隐藏 bug 在合入主分支前的代码检查阶段不会被发现吗？
|
 |
60
yunyuyuan 2023-03-24 16:39:20 +08:00
别的不说，money 有开发高吗
|
 |
61
buruoyanyang 2023-03-24 16:47:55 +08:00
坐标传统软件行业，工业信息化+工业自动化领域。之前测试的地位非常高，测试不放行，产品就无法发行；考核主要级 Bug 以及 Reopen 数，进入系统测试后，严格控制换包次数。相对应的，现场出问题，测试接全锅。
|
 |
62
bjzhush 2023-03-24 17:10:06 +08:00
《一个测试的 YY 》
|
 |
63
yufeng0681 2023-03-24 17:11:12 +08:00
任何一种制度，都有优缺点。
质量上精益求精，那么成本就会上去（发布时间拉长，人力投入加大） 开发团队也有可能变得保守，比如评估开发周期会拉长 30%，部分开发人员不愿意接复杂业务的模块工作，更愿意做简单，不容易出 bug 的模块。 做复杂模块的人因为 bug 多于做简单模块的人，考评排后了。 他要么也混起来，要么就会走掉。 研发战斗力下降，逐渐这个团队就废了。 大老板一看，测试太强，把研发团队干废了， 那怎么交付业务怎么赚钱！会换成 开发强势，测试弱势的玩法。 |
 |
64
IamUNICODE 2023-03-24 17:19:44 +08:00
作为开发，我觉得测试很重要啊，你们对自己写出来的东西这么自信的吗，我觉得和测试更像一种游戏吧，我写他抓，挺好玩啊
|
|
65
flyingghost 2023-03-24 17:25:11 +08:00
@zhaol #55
我不是说正常程序员应该不出 bug ，我也不是说团队里每个程序员都水平非常高。 但我想在软件工程里，开发测试产品都应该以逻辑严谨思维缜密作为目标，而开发在这一点上应该是最骄傲的才对。 做错了，就是做错了，就是水平不够。每个人有每个人的能力瓶颈，认识自我接受自我也是一种结论。但这不代表我鼓励因此对错误麻木。犯错，至少应该愧疚。 而且 bug 不仅仅和能力有关，还和性格有关（这个比较难改），还和工作方法有关（这个非常容易改进），还和思维方式有关（经过训练也可以改进）。工作方法和思维模式，我觉得也算软技能的一种。 团队里有粗线条的爱钻研的同学，写出 bug 连冒烟都过不了，气得测试叫呱呱。于是后来强调自测，强制给开发设底线，同时尽量让该同学做技术调研，少写业务代码。 有细腻的妹子，技术很一般，就 CRUD girl ，但真的很少 bug 。这大概归功于性格，很难学。 还有个奇葩男子，水平中上，产出率中，特技是不管写什么代码，永远零 bug 。月度总结报表里永远是零，偶尔才出个位数 bug 。。。后来他的工作方法和思考模式总结出来全组推广，都学学，都提升提升软技能。 谁说写 bug 就合理就不值得努力提高水平？ |
 |
66
Vindroid 2023-03-24 17:32:47 +08:00
见过公司 QA 按照发现的 bug 数量给项目奖金的吗？实机表现与 UI 标距有一个 pixel 的偏移算一个 bug ，只要和文档描述有一个字的差别也算一个 bug 。但是奖金只算发现的数量给，不算 bug 的大小，就导致一个项目 QA 提了上千个 bug ，然后 RD 再疯狂声明这不是一个 bug ，不需要解，整天的时间就耗在系统上让 bug open->close ，真正的 bug 都没时间解，所以我提桶跑路了
|
 |
67
wangxiaoaer 2023-03-24 17:48:31 +08:00 via iPhone
我觉得测试地位高没问题，只要背锅的时候能站出来就行。或者把测试换成质量控制、风险控制部门是不是就好理解了。
|
 |
68
blackshow 2023-03-24 18:02:28 +08:00
我还以为是 TDD
|
 |
69
cdlnls 2023-03-24 20:11:14 +08:00
我们这边测试总是测不出来问题，线上问题全靠客户反馈+异常日志。就希望测试能仔细测试，少点问题。
|
 |
70
WasteNya 2023-03-24 20:17:08 +08:00 via Android
在一个前端地位极高的团队是一种什么样的体验（手动狗头）
|
 |
71
jfcherng 2023-03-24 20:27:39 +08:00 1
 |
 |
72
Rakkael 2023-03-24 20:31:49 +08:00
跟某国企金融科技公司一模一样...
|
 |
73
shijingshijing 2023-03-24 20:39:10 +08:00
先看看有没有 MCDC 相关的要求，再谈测试的地位。没有的话，算不上高，更别提极高。
|
|
74
shijingshijing 2023-03-24 20:48:50 +08:00
真正把测试看得极高的公司，QA 和 Test 是分开的两拨人。QA 不关注结果正确，只关注程序正确； Test 才是真正执行测试的。QA 地位比 Test 高多了，独立条线，甚至可以汇报给大 Boss ，Test 倒可以外包。
|
 |
75
sparkpark 2023-03-24 21:01:28 +08:00
ToB 一般是这样
|
 |
76
wanghaa 2023-03-24 21:21:58 +08:00
深有同感啊，需求评审的时候测试不提意见，测试的时候一堆意见
|
 |
77
proxychains 2023-03-24 21:38:25 +08:00
@buruoyanyang 工业软件确实得严格点. 比如化工厂, 火电厂. 出现问题就是重大事故.
|
 |
78
sprite82 2023-03-25 00:30:28 +08:00
以前待过一个公司，测试提 bug 有奖金的，使劲逮着开发薅，像素级别找你问题，比如：这个配色太丑，这两个功能要换下位置，这个英文单词不行要换一个，特有缩写切换中文没翻译，想着办法给你提 bug 。有个同事比较菜，半年下来共享了几百个 bug ，直接送那个测试升了个职。
另外其他的一些测试也是鬼蜮伎俩频出，比如：有开发给其他组写了个工具，辅助调试的，根本不是正式的立项了的项目，传到测试那边，测试就对这个工具提 bug 了，什么功能缺失，不友好，特定功能有问题等等。甚至有些人还连到开发本地环境测试，测出问题提了 bug 过来。后面这两件事开发肯定不认的，bug 打回，测试还装委屈：我提都提了，打回影响我考核的。 测试可以随便叼开发，项目经理，客户的需求都不放眼里。因为没有产品经理，所以功能设计上，很容易被测试提 bug ，他们觉得怎样就怎样。这家公司可把我恶心坏了 |
 |
80
charlie21 2023-08-17 21:20:59 +08:00
楼上图片太搞笑
|
Select Language