这是一个创建于 1067 天前的主题，其中的信息可能已经有所发展或是发生改变。
是这样的，本人在开发过程中有几次出现线上版本出问题，领导警告再这样提桶走人。但是我想不通测试测好的程序出问题为什么要怪在开发头上呢。。。。
第 1 条附言 · 2022-01-25 16:58:18 +08:00
再求助一下，这个问题要不要和领导聊一下呢？？？？？？
 |
101
ElmerZhang 2022-01-26 01:42:10 +08:00 via iPhone  1
作为一个带过人也开过人的 leader 来说说。
开掉某个人的原因不是因为他做错了什么事，而是从那些事体现出来他是个什么样的人。 我带过的人中也有人送绰号 “bug 小王子”，虽然没办法给出好绩效，但仍然是团队主力的人。他出的错多，主要还是因为做的事情更多更复杂。 |
 |
102
Cielsky 2022-01-26 02:24:42 +08:00 via Android 1
|
 |
103
akira 2022-01-26 07:13:01 +08:00
做人 做事，要有担当
|
 |
104
zjb861107 2022-01-26 09:02:18 +08:00 1
说得好，开掉测试吧，全靠开发自测怎么样？
|
 |
105
VShawn 2022-01-26 09:06:45 +08:00
抛开事实不谈，领导就没有一点责任吗
|
 |
106
yaphets666 2022-01-26 09:13:23 +08:00
@KarlChen2015 公司应该发你两份工资
|
 |
108
timlong 2022-01-26 09:46:32 +08:00
我觉得这个测试和开发都要背责任，只要经过测试的产品，测试同学就应该对其结果负责，同时，开发同学也应该对自己开发的功能负质量的责任，两个人是一条线上的蚂蚱，谁也逃不掉
只不过，看要线上故障的具体场景和原因，来分开发同学和测试同学的主责和次责，如果是很明显的漏测或者开发同学提测建议里面明确提到过的场景，那么毫无疑问是测试同学主责，甚至全责；如果是功能实现的边界但是开发同学没明确告知，导致测试同学的用例设计有问题，出现的漏测，我认为应该是开发同学主责，最后，如果是谁都没想到的一些边界或者环境问题，可能就是五五开了 本质上我认为这个功能的开发和测试同学都应该对功能的质量和最终结果负责，双方在这一点上应该是利益共同体才对 |
 |
109
zw1one 2022-01-26 09:46:43 +08:00
领导的问题呗，拿那么多钱又把控不了开发流程。我待的几家有生产问题都是领导主责。
|
 |
110
Exple 2022-01-26 09:52:55 +08:00 via Android
只有我觉得是领导 /公司的问题吗？只要是程序就肯定有出错的可能性，再怎么测都不能绝对 100% 没问题。出了问题就警告要辞退的风气才是不对的。正常一点的公司是应该做 blameless postmortem 的。
当然互相推诿扯皮甩锅也是不对的。 |
 |
111
iMiata 2022-01-26 09:54:13 +08:00
@loriann #8 如果测试阶段 测试没有测出问题给了通过，版本上线以后发现的问题自然是测试的全责（或者测试负 80%以上的主要责任）
|
 |
112
lonenol 2022-01-26 09:54:46 +08:00
不要整精神啥的。。
正常企业制度，测试完成上线测试主责，没通过测试自己私自改动就上线开发主责 |
 |
113
tiedan 2022-01-26 09:57:45 +08:00
一般实践是所有线上问题 QA 都有责任（有些公司甚至包括机房断电这种），如果是代码问题 RD 主责。线上大问题一般是负责的 RD 打包走人，QA 扣绩效
|
 |
114
txy3000 2022-01-26 10:02:41 +08:00
把测试开了 测试的钱给开发 开发自测 是不是完美
|
 |
115
cassidyhere 2022-01-26 10:05:48 +08:00
如果一个员工的职责是“给你一份代码，把里面的 BUG 全找出来”，那该员工的薪资应该是写这份代码的人的两倍
|
 |
116
NotFoundEgg 2022-01-26 10:09:05 +08:00
既然是测试通过之后出的问题 那自然是测试主锅 不然还要招测试干啥
|
 |
117
satoru 2022-01-26 10:10:29 +08:00
要让 QA 帮开发背锅，他们是拿两份工资吗？
|
 |
118
EricGoodMan 2022-01-26 10:12:03 +08:00
@cassidyhere 测试是找代码的 bug 吗，还是找功能的 bug
|
 |
119
LuciusChen 2022-01-26 10:13:26 +08:00
自己写的 bug 没有责任？开发又不是单纯开发，开发完要自测要联调，转测后就不自测了？开发和测试的视觉不一样，都需要去测试。
我本身是程序员，主张程序员主要责任，测试次要责任。 |
 |
120
chairuosen 2022-01-26 10:22:22 +08:00
如果测试过程中 BUG 多开发需要担责，那测试完成线上事故应该测试担责。
如果测试过程中程序多烂开发都不用担责，线上事故开发测试同责。 我们可以黑盒的看待这个问题，两个人在两个阶段配合完成一个任务，那两个人的责任是同等的。要么按时间先后来区分责任，要么最终责任各半。 |
|
121
chairuosen 2022-01-26 10:23:27 +08:00
@chairuosen #120 不应该出现无论 A 做的怎样，都是 B 担责的情况。
比如无论开发多烂，线上事故都是测试担责。无论测试多烂，线上事故都是开发担责。 |
 |
122
Thresh 2022-01-26 10:26:48 +08:00
@l00t 没有啊，appops 都是开发和测试在搞。
我所经历过的，腾讯游戏还有传统的运维，而其他的互联网公司都没有传统运维了。只有管机器资源的资源组和管数据库的 dba ，dba 还常年不出现，不出线上 db 问题不出现。 资源组的又都是自动扩容了... 除非预算没了，否则他们也不出来。 打包发布、实时监控、线上问题的应急和处理，都要开发和测试自己搞的，开发和测试的手机是不能关机的呀...随时可能有告警电话打过来的。我所了解的互联网公司基本都是这种模式呀..... |
 |
123
MoRun 2022-01-26 10:29:49 +08:00
都有责任，开发负主要责任
|
 |
124
shyrock 2022-01-26 10:32:07 +08:00
@txy3000 #114 对啊，我就是这个观点。如果开发自测水平足够，是不需要专职测试帮你搽屁股的。你想拿测试那份钱，只要向老板证明你的代码质量足够好就行了。
|
 |
125
751327 2022-01-26 10:57:36 +08:00
看来看去，感觉没必要有测试这个职位，真没用
|
|
126
751327 2022-01-26 10:58:45 +08:00 1
你永远可以说是开发的锅，准没错
|
 |
127
Ryan7sz 2022-01-26 11:10:36 +08:00
测试同学说一句，需要具体问题具体分析。
- 如果是主流程没通，开发测试责任五五开 - 如果是测试方案评审过但是测试漏测的情况，开发测试责任三七开 - 如果是测试方案中没有的、系统内部的、白盒才能发现的问题，开发测试责任七三开 一根绳子的蚂蚱，出现猪队友，大家一起倒霉 |
 |
128
Lucas1024 2022-01-26 11:12:10 +08:00
责任问题了，说实话 东西是你开发的 你比任何人都要清楚。。
|
 |
129
beshe 2022-01-26 11:40:26 +08:00
测试，又名‘背锅侠’， 绝非浪得虚名，O(∩_∩)O~
工作中很多人或多或少对测试都有一些偏见，觉得没啥技术含量，但出问题背锅担责又是第一位。 这个主要看每个公司的文化，对流程管理和测试过程是否重视。 现在快速迭代开发中，强调开发测试合作更紧密，具体情况具体分析吧。 |
 |
130
kriko 2022-01-26 11:52:47 +08:00
领导挺拉的
|
|
131
Cielsky 2022-01-26 12:23:39 +08:00 via Android
@timlong 谁都没想到不应该是无责吗。
毕竟人又不是机器，写出 bug 是在所难免的事，如果这个也得五五开，那领导全责 |
 |
133
tktk 2022-01-26 13:14:15 +08:00
看测试用例，看冒烟用例啊。测试有没有覆盖，没覆盖且是业务故障就是测试的锅，如果说测试说不知道这个业务那就是产品或者开发私自改动了。知道但没覆盖就是测试的责任。覆盖且通过那就是开发的锅。环境问题也是开发的锅。
|
 |
134
Guesser 2022-01-26 13:48:22 +08:00
急了急了，线上出问题，整个项目组都是一荣俱荣一损俱损的，急着甩锅没有用，怎么改善才是重中之重
|
 |
135
bk201 2022-01-26 13:50:43 +08:00
我们说了不算，leader 说了算。
|
 |
136
uiosun 2022-01-26 13:51:31 +08:00
|
 |
137
junksheng 2022-01-26 13:58:38 +08:00 via Android
测试只是尽量发现问题，而不是保证完全没问题
|
 |
138
Chad0000 2022-01-26 14:02:51 +08:00 via iPhone
我就问问如果上线了没有问题你有没有奖金？你写的代码测试测不出问题来有没有奖金，没有的话爱谁谁吧
|
 |
139
flanker 2022-01-26 14:18:30 +08:00
按照我司的操作，出这样的问题，开发组长、开发者、测试都要罚
|
 |
140
kiripeng 2022-01-26 14:23:39 +08:00
当然是测试小锅，开发大锅呀。
|
 |
141
yyttrr 2022-01-26 14:49:42 +08:00
第一次你大锅测试小锅，后续的你全锅
|
 |
142
lxd152 2022-01-26 14:51:06 +08:00
@darknoll 不重要的 bug 一堆，那么只能说明你写的代码很 low ，写一行是一行，也不做自测，。负责任的开发是不会写一些明眼就能看出的 bug 。
|
 |
143
wd 2022-01-26 14:54:50 +08:00 via iPhone
你想想测试的工资和开发的是不是一样多
|
 |
144
yongzhenchen682 2022-01-26 14:55:52 +08:00
嗯，测试场景都过了吗？就是把测试案例拿出来开会讨论，如果一堆人都没人提出这个问题，测试不主锅。如果有涉及到这个场景，测试没测，测试主锅。这是基于业务的测试。
如果是内存溢出之类的问题，业务测试测不出来，开发代码稀烂之类，还得问问自己或测试是否压测过。 |
|
145
lxd152 2022-01-26 15:00:59 +08:00
身为测试~想说几句，仅代表个人。首先 bug 出现，那么肯定就有问题。那么问题是大，还是小。业务逻辑问题，还是代码异常，还是崩溃，还是性能问题等等。标准的产品测试流程：开发单元测试-->冒烟测试（正向主流程业务，开发测，测试提供用例）-->测试进行全面测试---产品验收测试。所以如果标准化，出现 bug ，谁都有锅，只是取决于 bug 大不大，有没有造成损失，到底要不要追责，等等等等。几年的工作经验告诉我：有 bug 就解决，不要第二次发生。bug 是不可能完全没有的，只能尽可能的做到更少的 bug ，更优的代码。都是 team ，大家都好好写，好好干，帮别人也是帮自己。
|
 |
146
leafre 2022-01-26 15:11:50 +08:00
其实只是领导看你不顺眼，想开你。
如果是测试的职责，如集成、端对端就是测试的锅，单元测试范围是开发的锅 |
 |
147
gologle 2022-01-26 15:31:14 +08:00
责任的划分，与项目的性质相关，假设如是高并发面向 C 端的产品，则责任可以这样划分。
对于开发， 假设上线前，测出的 BUG ，开发须承担的责任为 1 ， 则上线后，出现的 BUG ，开发须承担的责任为 2 。 也就是说，BUG 的产生，开发必然有责任，若在测试阶段就发现，则责任小一些，拖到上线再发现，责任翻倍。 对于测试，上线前测出的 BUG ，测试须承担的责任为 0 ，即无须承担责任， 而上线后，出现的 BUG ，须承担的责任是 2 ，即与开发负同等双倍责任。 |
 |
148
linglongll 2022-01-26 16:17:52 +08:00
点工没点全呗 如果出现的问题不出现在测试用例中的话 那就说明出的测试用例不全啊 不全的话谁的锅不用说了吧 公司都是各司其职的 开发的任务就是开发 测试的任务就是测试 不用去管极端的例子 出了问题俩人都得担责 但是从职责角度看确实是用例覆盖不够广泛 或者你们可以一起骂产品出的东西逻辑复杂了 众所周知 如果写一行打印 hello world 的话是不会出问题的 只能说老哥你的 leader 做的有点不妥 但是想想 你出问题了 你的 leader 是不是也不大好过呀 他不爽了你还想爽是不是不大可能呀
|
 |
149
FranzKafka95 2022-01-26 18:11:38 +08:00 via Android
源头在开发，你是头，测试来把关，把关没把好也有问题。当然，你们领导问题最大，他为什么不考虑从流程体系上去减少这种个人的错误，降低这种失误流出的概率。
|
 |
150
UIXX 2022-01-26 18:24:28 +08:00
是什么 bug 不说，很难对整件事进行评估。我倾向于具体案例具体分析。
|
 |
151
xumng123 2022-01-26 18:52:31 +08:00 via iPhone
我所在的大公司，一次性干得好的不如经过很多次攻关的绩效好，多次攻关可以给领导一种这个事情难度很大的错觉。多经历几次后，大家都有样学样儿，简单的事情复杂化都是常态了。
|
 |
152
Akiya 2022-01-26 19:01:39 +08:00
我觉得 V 站水平还有待提高，视野不要局限在甩锅给谁好吗？
我的建议是把具体的问题贴出来这样更好讨论。 很有可能是流程导致的问题，比如说： - 代码没有充分 Review - 没有自测就提给测试 - 测试的测试用例设计没有评审 以上都是可以规范流程解决的。当然你一定要依赖于员工自身的能力也不是不行，那就请提高面试官的水平和薪资，能准确判断出靠谱的工程师，公司的产品出了线上问题当然是公司负责，怎么轮得到一个打工的背锅。如果开发的功能除了问题就要离职，那请问是不是这个功能产生的收益是不是全归你啊？ |
|
153
xumng123 2022-01-26 19:06:14 +08:00 via iPhone
具体到开发和测试外泄的这个问题，通常我司的做法是：
1. 开发先上，将错误以冠以临时解决方案堵住—发补丁； 2. 开复盘会议，会议上开发测试互相 pk 甩锅，直到僵持不下，然后领导各打五十大板。第一次复盘失败； 3. 开发测试回去各写整改报告，开发强调后续加强提高覆盖测试用例，测试强调后续加强测试方法与用例覆盖。 4. 第二次复盘会议，开发汇报并给出提高测试覆盖的目标，测试汇报给出测试方法改进与提高测试覆盖的目标。会议圆满结束。 5. 一段时间后，第三次会议，汇报目标完成情况。 6. 经过若干个月，再次出现故障外泄，重复以上动作。 … 7. 价值需求交付越来越少，为了保持需求交付效率，需求拆的越来越小，部门人数越来越多，团队越来越多，各个角色就越来越多，会议越来越多… |
 |
154
4771314 2022-01-27 10:36:54 +08:00
锅要分清
如果是测试没有覆盖到，那测试也是有问题的 如果是测试环境没有问题，上线后出现问题，研发问题大一些，但是测试也是有问题的 总之就是，版本线上问题，所有环节的人一个都跑不掉，这是铁定的，就看老板怎么想了 我们一般都会复盘，基本是大家都分一点责任，不会集中到一个人身上，毕竟是一个团队，这样所有的锅都给一个人，是在是有点说不过去 一个正常的版本，产品提需求->需求评审->UX->UX 评审->开发->提测->上线->回归，大家都在流程里，如果出了问题，不能全怪开发（除非这些环节都是开发一个人负责），上线奖励大家都有，出了问题开发一个人背锅，这是不合理的 之前也遇到过，创业公司，小团队，4 、5 个人，有段时间，需求很赶，上线出问题的次数有点多，leader 的理解就是全部都是开发的问题，经过几次的辩论（撕逼），才有了比较合理的复盘和责任认定机制。 对小团队而言，最容易出现，一出问题，研发祭天的情况，需要时间和经验。 |
Select Language