大吵一架，开发跟测试真的是水火不容的吗？

[wx497657341]

今天跟测试同事大吵了一架，现在心里特别不是滋味，忍不住想问问大家：开发和测试之间真的只能是针锋相对的关系吗？

事情是这样的，我是一名开发，最近刚把一个功能部署到测试环境。本以为能顺顺利利推进测试流程，结果测试同事在测功能的时候，感觉根本没吃透需求文档，操作的时候完全是凭着自己的理解 “瞎点”。有些功能逻辑需要特定的前置条件才能触发，他没按正常流程走，最后没得到预期的数据，二话不说就直接提了个 bug 。

我看到 bug 描述的时候有点无奈，就跟他说：“这个功能的逻辑在需求里写得很清楚，建议先把需求吃透再测，不然很容易误解功能设计。” 结果这话一出口，他立马就不爽了，觉得我在质疑他的工作能力，两个人你一言我一语就吵了起来。

其实我完全没有针对他的意思，毕竟开发和测试的目标都是让产品更完善。但这种因为需求理解不一致引发的冲突，真的太影响工作效率了。想问问大家，平时开发和测试之间都是怎么沟通协作的？遇到这种需求理解偏差的问题，该怎么解决才不会伤和气呢？

[mumbler]

测试就不应该按正常流程走，才能发现问题，如果是功能设计的问题，你应该把锅给产品，而不是跟测试去吵

[georgetso]

为什么要认真工作？不可以摸鱼吗？打个工有必要吗？

[peteretep]

1 、测试就是测试各种意外的，如果有前置条件没有完成，系统需要拦截，或者给出提示，不能要求测试自己预先知道这个知识
2 、加上产品一起吵

[Dillan]

对方已经诉诸情绪了，就先解决情绪问题，再想办法解决工作的问题。

[hidemyself]

”有些功能逻辑需要特定的前置条件才能触发“
没有走到特定的前置条件就触发了，这不就是 bug 吗

[leehomyhh]

挺搞笑的，测试就是随便点啊，点出 bug 就是 bug ，不然都按照正常逻辑来点，还要测试干嘛

[belin520]

测试就是干这些边界 bug 查找的

[zhangciangming]

你敢保证用户不会这样操作？

[Smileh]

你觉得不是 BUG 就 打回这个 bug ，
然后附上原因， 如果还有疑问
就拉着产品确定

[wangtian2020]

客户会管你随便点击吗，随便点不出问题是最基本的要求

[ice2016]

得有容错处理和提示信息。

[zpvip]

这种同事要珍惜, 他做的是 smoke test, 就是要瞎点, 不能有意外, 如果不换流程, 你得有提示用户哪做错了啊.

幸好你系统没交付就测出意外了, 你要感谢他.

[choah]

做产品要把用户当傻子对待

[Vraw5]

用户是傻 x 啊。
前置条件？用户：我不造啊。

[yuanmomo]

@zpvip 不是 exploratory 测试吗？

[newaccount]

这不就是你没判断被除数不能为零吗？还能怪测试？

[onebyone]

好的功能就得要经得起各种测试，实际使用中一些客户的操作方式可能比你们的测试更离谱

[wx497657341]

@hidemyself @leehomyhh @zhangciangming @wangtian2020 @ice2016
是一个国外的项目，需求是用户上传技能证书图片、PDF ，后端解析出格式化数据，存储到草稿表。上传完成后用户跳转到证书编辑页面，将解析的数据填充到表单。

之前一直都是有证书无效的原因的，但是上次一个需求改成了：如果证书不是本人的或者证书无效则不给前端传数据。

测试一直用他的账号上传别人的证书，数据库清清楚楚记录下了原因。

@Smileh 确实应该拉上产品

[HelloWorld23333]

显然是你的问题。首先随便换一个项目负责人都不会站你的。
*优先测试提的问题，是可以不改的
*测试提单那是他的本职工作
*测试阴阳怪气，你生气就会占下风
*测试工资不高的，拽里拽气的不用管

破解心法：“是 bug 淡定” ，“是 bug 淡定，天没塌下来”，测试抱怨：“你要自测再给到我”，回：“都是测过的，程序无法自证没问题”。“你把日志取出来，最好有录像，我好重现修改”。程序一定要淡定，这样就显的测试大惊小怪的

[spritecn]

年轻了,这种事回邮件/JIRA ,@一下产品就好, 你这回复就有点找架吵的意思

[SoviaPhilo]

这个已经很不错了。

我告诉你什么情况下能做到开发测试水火不容

1. bug 逃逸作为测试的 kpi 指标
2. bug 发现作为开发的 kpi 指标

只要这么做，再配合绩效扣钱， 就能让开发和测试彻底撕裂

[strobber16]

活该

[SenLief]

功能产品问题应该是产品经理的问题吧，测试本身就是测试所有可能的情况的。

[Thresh]

如果确实是你描述的，连 prd 都没吃透就提了个 bug ，QA 的问题。
--- 14 年 qa tl

[coderluan]

这事可以不吵架，楼主的沟通存在问题，起码你得把这个问题本身解释清楚，然后再评价对方没吃透需求。

[BeforeTooLate]

@wx497657341 #14 那你前端应该返回原因弹窗的吧如：上传的证书不是本人的或者你的证书是无效的。
看你描述记录在数据库，不知道测试的时候前端页面是否没得到反馈？

[lqm]

我觉得你在网暴自己，我不会这么跟测试说话

[dna1982]

@SoviaPhilo #21 我怎么觉得你这两个指标不矛盾啊。

把 开发的 kpi 和 测试的 kpi 同时定为 BUG 发现率，但是指标要求相反。
发现率高了扣开发的钱，发现率低了扣测试的钱，这样才是水火不容。

[gorillaL2sll]

@wx497657341 那这个页面也得返回证书不是本人啊

[BenCoper]

是不是作为开发大家都觉得测试提的 Bug 很无语呢？
作为半业务测开（点点点+工具开发），我测业务的时候遇到 Bug 都是先拉开发一起看下这个 Bug 复现的操作步骤和后台日志一起对下看下问题出在需求还是代码上。
确定是 Bug 后我才会提 Jira ，所以个人感觉这种方式是不是最好的呢我也担心测出来不是问题是操作上的问题或者各种奇奇怪怪环境的问题。
最后我只想说只要测试没有以 Bug 作为 KPI ，研发团队的氛围就是一个天一个地。

[EmptyDX]

用户也需要吃透需求文档，按正常流程走？

[JSONstringify7]

问产品要个提示内容，加上提示就可以解决了。至于干架吗

[Alloyt]

@wx497657341 “如果证书不是本人的或者证书无效则不给前端传数据。测试一直用他的账号上传别人的证书，数据库清清楚楚记录下了原因。”，哥们你是在网曝自己吗？测试这样做是没问题的，这是一个测试程序是否会产生异常的常见方式。你不能预设用户会按照正常的流程走。

[wx497657341]

@BeforeTooLate @gorillaL2sll 之前有返回，每个错误原因都有，后面的需求改了

[nunterr]

如果测试没按照需求做常规测试，提的 bug ，明显是有问题的，测试不是点点点，
一方面测试需要用正常流程测试，当然也需要异常流程测试，提的 bug 也是不一样的，而不是根据自己想象提 bug

[hefish]

能动手千万别吵吵。。。

[nunterr]

当然这些没必要吵吵的，工作就是工作，指出问题就好了，他不接受，那就开会的时候提出来就好
虽然我也是个测试😂

[Vegetable]

那你就找产品，把这个预期之外的情况写到需求里边去，让他变成预期内的。别在这理所当然。

[fredweili]

错误保护太差了，普通用户就是会瞎点，99%的人根本不会看用户手册
有事说事，“建议”别人怎么做事，不是领导就没这个资格

[kneo]

需求：第一步 A ，第二步 B ，得到结果 C 。

测试：第一步 A ，没有结果 C 。

开发×：你没点 B 。好好看看文档。
开发√：第一步 A ，第二步不点 B ，结果应该是 D 。 @产品。

我相信需求里肯定是没有写不执行 B 结果是怎么样的，否则肯定是测试的问题，你也不会来抱怨了。

没有明确文档化的行为都是有一定周旋空间的，友好讨论。

==================================
（以下是如果真的吵起来，从开发角度怎么维护自己。）
==================================

如果你觉得从流程上讲，测试不应该——或者说无权——给未定义的行为定性为 BUG ，你可以向经理反馈。可以要求测试先与开发或者产品讨论，达成一致再发 BUG 。

也可以要求对测试提交的 BUG 有效率进行评估。如果测试最近发的十个 BUG 里有至少三个都是无效 BUG ，那你可以说测试没理解需求，瞎点。

=================================
（以下是如果真的吵起来，测试角度可能怎么针对。）
=================================

作为测试，可以申明立场：需求文档中能明确覆盖的只是真实测试工作量的十分之一。

如果只需要测文档中写的内容，那测试可太轻松了。评估测试工作量的主要参数就是测试能想到多少文档外的未定义路径。

测试可能明确提问：如果文档里没写的用例，不让测试去负责，那么用户点了发现问题，是谁的锅呢？

测试可以向管理要求，明确测试有对未定义行为发 BUG 的权力。

测试可以评估所发 BUG 中，有文档定义的 bug 的比例。如果比例大于 50%，说明开发质量太差，基本的需求都实现不了，一测就一堆问题。如果比例小于 50%，强调测试自由发挥的重要性，大部分 BUG 都是测试在探索未定义行为时候发现的问题。

[thomasyxy]

测试和开发应该是一边的，工作中大部分矛盾来自不合理的项目排期管理和有限的研发资源之间的矛盾，排期紧张或者需求变更导致矛盾被迫转移到了开发和测试之间

[woodfizky]

开发和测试的利益完全看公司怎么管理和设计奖惩制度的。

测试独立出来成为一个职能的目的，就是用不同于开发人员的视角（尽可能的贴近用户）来对程序功能做测试。
本质上是为了尽可能避免项目进入到投产阶段之后才发现问题，轻则导致返工，重则造成损失。

按我的理解，正常情况下，测试帮你把 bug 测出来了，是好事情。
如果是程序逻辑上的问题，那你确实要感谢他；
如果是产品设计上的问题，那你们应该一起找产品，讨论设计是不是真的不合理，不合理的话怎么修改设计；

除非你们公司属于那种被测出来 bug 就要扣绩效的，那我建议你跟管理层反馈一下这个制度的不合理，或者干脆换一家公司。

[wayfarer]

做了这么多年开发，我还真没怎么跟测试吵过架，倒是经常和产品撕逼。

[darkengine]

我告诉你，有些用户的操作比测试人员还无厘头

[aduangduang]

测试的目的不就是帮你查漏补缺，堵死预期外的路径？只测正常路径功能是否实现，那需要测试吗？

[irisdev]

这次我站测试。1.看描述没有提紧急 bug ，你最好的做法是商量看能不能关掉或者有时间再改 2.“根本没吃透”，指望测试吃透有点强人所难了，你说的话是有点阴阳怪气，有时间跟他说怎么回事，没时间就转产品

[niboy]

我和客户吵过，我和领导吵过，但从来没有和测试吵过，我认为是伙伴，就跟狙击手有个观察手一样。
测试是帮助开发找出问题的，是让产品完善的。
测试可以提 case ，但如果不是问题，开发可以解释。
如果有争议，可以开多人评审会议，集体讨论，领导拍板一下。

[kakakakaka8889]

测试不就是瞎点吗？要是都按流程来那还有什么 bug 呢？既然有前置条件你就拦截啊，没有弄完前置条件为什么要进行下一步呢？你的问题比较大，用户管你这的那的

[fancy2020]

和 lz 的情况有点相反，有种测试更无奈，每让她测一个功能都让开发给她讲一遍测试流程和测试点，这不应该她自己读需求然后自己设计吗？倒不是怕费劲，问题是这种流程如果是开发告诉她了，那还要测试干嘛呢，开发自己就测完了，测试就是应该按照自己的方式去测才能测出问题啊

[spritecn]

@BenCoper to 30,等你写完 jira,我已经改好了

[bojackhorseman]

@wayfarer +1

[tongbufu]

没 UI 啊 就靠狗产品那个破原型？

[ferock]

不要两人讨论，至少三人

[oscarxie]

测试用例里面包括正常用例和异常用例，正常用例我相信开发自测的时候都能覆盖到，那么测试关注的重心肯定在异常用例上，本来就是来搞破坏的，所以除了正常功能点验证后，测试肯定是随便点的，这个叫做探索性测试，根据测试人员对业务的熟悉程度以及长期使用项目或产品的感觉，专门就会做集成测试或者说重点关注有关联的地方，因为单一开发只会关注自身开发的功能模块，比较少关注和其他开发一起集成的功能。
不知道你们的研发流程怎么样，按理说，需求设计测试用例都需要评审的，在全员认知一致的情况下，很少需要争吵，毕竟需求有争议是可以找产品经理明确的。

[vipfts]

@mumbler 这算啥, 我们公司开发给测试吵哭过, 开发还有过周末拉男朋友来公司加班帮忙改代码

[wx497657341]

下次直接拉上产品🤣

[feaul]

老段子，测试本来就是为了用户不遵守规则，而导致系统崩溃或者造成无法使用吗？
一个测试工程师走进一家酒吧，要了一杯啤酒；
一个测试工程师走进一家酒吧，要了一杯咖啡；
一个测试工程师走进一家酒吧，要了 0.7 杯啤酒；
一个测试工程师走进一家酒吧，要了-1 杯啤酒；
一个测试工程师走进一家酒吧，要了 232 杯啤酒；
一个测试工程师走进一家酒吧，要了一杯洗脚水；
一个测试工程师走进一家酒吧，要了一杯蜥蜴；
一个测试工程师走进一家酒吧，要了一份 asdfQwer@24dg!&*(@；
一个测试工程师走进一家酒吧，什么也没要；
一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来；
一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿；
一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷；
一个测试工程师走进一家酒吧，要了 NaN 杯 Null ；
一个测试工程师冲进一家酒吧，要了 500T 啤酒咖啡洗脚水野猫狼牙棒奶茶；
一个测试工程师把酒吧拆了；
一个测试工程师化装成老板走进一家酒吧，要了 500 杯啤酒并且不付钱；
一万个测试工程师在酒吧门外呼啸而过；
一个测试工程师走进一家酒吧，"< script >alert("要了一杯酒");< /script >"
一个测试工程师走进一家酒吧，要了一杯啤酒';DROP TABLE 酒吧；
测试工程师们满意地离开了酒吧。
然后一名顾客点了一份炒饭，酒吧炸了。

[Sfilata]

这个很简单啊，看是不是真的测试问题。如果是的话就 bug 回复清楚，写明不修复就行了。这点事我都不会和他有任何线下或者其他方式的交流。如果真的是那种用户很容易触发的异常流程，还是做好权限管理和异常检测吧。大不了弹个框啥的挡住就可以了。

[NizumaEiji]

流程不健全，就会导致沟通不足，产研测对需求的理解不在一个点上，出现这种事太常见了。
而且说实话对于研发来说，测试从来都不是你的敌人，少一点对抗的心态比较好。

[Cloud9527]

测试没问题，实际用户就是瞎用。你不能说用户瞎用出 bug 是用户的问题吧，最后不还得自己改 bug 吗

[xiaofeixiang]

我是开发，碰到这种，不要怪测试没理解需求，测出来有问题要么是没容错，要么是产品没定义清楚，最好拉产品一起讨论，可以甩锅不是你产生的 bug ，但是不要情绪化，解决问题为主！测试提出来，总比上生产被用户点出来然后半夜拉你起来做生产回滚好

[json12138]

如果在一个工区，可以去和测试当面沟通。当面沟通远比文字更有温度
终究还是沟通问题
搞好同事关系，主打一个嬉皮笑脸

[RanKaede]

没按正常流程走，最后没得到预期的数据肯定不是 bug 啊，即便系统崩了那也是其他的 bug ，跟流程又没关系

[lanshee]

1.测试没问题
2.你没问题
3.产品设计问题

[bbao]

@Thresh 这位 14 年 qa tl 不太行啊～～～

[kyrieIvring]

1 、测试用例有没有拉你跟产品一起评审
2 、分清属于功能缺陷还是设计缺陷
3 、拒绝之前，先说怎么样能得到正确结果，而不是上来“你没吃透”
4 、都是牛马，他有他的任务，说实话，我感觉遇到一个不按常理出牌的测试，更能减少上线前的 bug

[BoyzX]

我觉得测试本来就有问题。。。测试可以不按照需求点没错，但是测试应该先抓住重点，按照需求文档，测通需求，然后再随便乱点来测试程序的所谓稳定性。而不是本末倒置的先关注非需求问题，如果这样工作是没办法推进的，就像你本来是去超市买西瓜吃，然后看到勺子和刀，你就开始想要用刀切然后用勺子舀西瓜吃，然后你的关注点就转移到买哪把刀和哪个勺子漂亮？难道不是先选个最满意的西瓜么？

[starix]

@wx497657341 按照你 18 楼说的这个问题，我觉得是产品问题：
“之前一直都是有证书无效的原因的，但是上次一个需求改成了：如果证书不是本人的或者证书无效则不给前端传数据。”
这点本身就有问题，用户对内容的认知是由系统给与的，上传上去连个反馈都没有，换做是你不觉得有问题吗。
这个反馈要给客户端，至于客户端怎么提示由产品自行决定。

[iMiata]

我项目组的人现在都是有啥来找我，是测试的问题我就去跟测试讲清楚需求，是开发的问题我会让开发按照正确的改，虽然我会累一些，但是他们会很和谐，合作效率也会高一些，仅供参考

[wx497657341]

@starix 已反馈给产品了

[ahjsrhj]

我之前碰到过一个测试
一个 H5 页面, 有个倒计时, 结束了按钮置灰不样点
测试提了个 bug, 演示了下他的操作方式
打开页面, 接口返回了一个 50 多万秒的时间进行倒计时, 然后他打开数据库软件把库里的时间改为 0
问我页面上按钮怎么没灰

[leonidas]

@feaul 生动 形象 哈哈哈哈

[Thresh]

@bbao 哈哈哈 是吧？

[Autonomous]

不要觉得测试是傻宝，因为用户是傻宝，测试只是在模拟用户

[canteon]

都是牛马，看评论区比你问的这个问题都有意思。

[bloomy8]

@mumbler 要看情况，有些测试会 mock 一些线上不可能出现的路径最后导致异常，这种就没什么意义

[wzy44944]

这种没有提示拦截导致的问题，的确算 bug ，算交互设计方面的问题，让他提给产品就行，不是所有的 bug 都是提给开发的，提 bug 流程里面一般应该有一步，就是责任人可以修改 bug 类型并转交给其他责任人

[BenCoper]

@spritecn #50 改好了我就不提 Bug 了，经常这样。但是有些重要的提交涉及很多模块的还是会记录下因为涉及到工时时间比较长要录入，所以还是那个问题 Bug 不是 KPI 都是小事情。我还不想提呢哈哈耽误我测

[patrickpu]

心平气和，少用强语气词，对事不对人

[GetMoneyMan]

混饭吃嘛，你提了能改我就改，改不了我就转给产品或项目经理去搞。

[jcy]

首先测试应该先覆盖需求，其次再是一些异常操作。还有应该是你们整个流程有问题吧，测试的依据是什么？是测试用例，测试用例需要评审的，他没有按着测试用例测也是有问题的。

[siaronwang]

https://www.v2ex.com/t/1153969 开发给谁都能 pk

[unco020511]

你们没有测试用例吗,用例不合理那就是测试的问题

[GuLuDaDuiZhang]

我见过的都是排期紧，测试和开发都没人力没时间，虽然提测了，但只开发了个大概，然后测试就类似于在帮研发自测，保障基本功能流程没问题，好点的再发现些需求和研发没考虑到的逻辑，以及从用户视角出发看看有没有体验类问题。

op 遇到的可能是测试提了个不在需求里的体验类问题，这种情况应该转单给产品看吧。去讨论是不是 bug ，就容易变成测试和开发之间扯皮，理想情况应该把问题单传递出去，让项目组决策改不改，要改就给个逻辑照着改。

[air1314]

我一般不和测试起冲突，他提 bug 就提呗，如果觉得不是我的问题打回去就行了，如果是测试没做到位，一般多打回几次，他也会注意点，不会随便提 bug 来了
我只讨厌不专业的测试，把一些测试 scope 里的东西推给我去帮忙解决，占用我时间的

[queifa]

你只需要在 bug 单上恢复一句：产品设计如此，把问题扔给产品。

[chenmobuys]

你这话，什么人听了，心里都会不舒服吧，还建议把需求吃透。。。好好说话不行吗
测试能在上线前尽早把问题测试出来，我感谢他都来不及，搞不懂你对他意见为什么这么大。

[supuwoerc]

退回 QA 的问题，备注：“设计如此，这是产品的设计问题”

[darluc]

开发跟测试是水乳交融的哈

[nuo7mi7]

@wx497657341 #18 这不就是一条 case 吗，很合理啊，测试不就是要测试各种意外情况，难道你要测试按你想的来测，那还要测试干嘛

而且你说话也不太对劲，一看就是直男死板程序员，不会好好说话，你说的“这个功能的逻辑在需求里写得很清楚，建议先把需求吃透再测”，你这不就是在质疑人家的工作能力，就算你真有这个意思，你也不能这么说啊，情商堪忧

见了太多这种死板程序员了，不喜欢沟通只会默默敲代码，沟通能力、人际处事能力差的要死，一个好的程序员可不仅仅只是敲代码，沟通能力远远大于代码能力

[amenceliu]

明显是开发的问题啊，测试就是要跳出各种前置条件

[nuo7mi7]

@Thresh #24 万一用户就会这样操作的呢，这不就是一个 bug 吗，不管是交互还是没出对应提示 toast

就算用户不可能触发这个逻辑操作，开发完全可以回一个：线上用户是触发不了这个逻辑的，不用管这个问题，然后这个 bug 不置会就可以了，然而他回了个：这个功能的逻辑在需求里写得很清楚，建议先把需求吃透再测，这种谁听了不恼火

[lesterchen]

作为一名测试.我好像从来不直接跟开发吵.因为没意义.吵不出什么结果来.我都是跟开发一起和产品吵.跟产品一起和开发吵.或者看着他们两吵.然后给我一个结论.

[Stupid22]

气大伤身、更它吵没有意义
最后可能还得是你改

[lucays]

这是你的问题噢

[chatgptnext]

写代码不是打打杀杀,是人情世故. 你说话方式欠妥,我看我也红温

[holmesx]

@BenCoper 个人觉得这个流程不太对。。。 首先，合格的测试，应该有能力判断出当前的场景到底是不是问题，如果判断出了是问题，即便是优化类的问题，那为什么还要找开发一起看下？测试别的工作就不干了，干等着这个结果么？这个效率是不是太低了？至于问题出在需求上还是代码上，这个是开发和产品应该有能力判断出来的事情。

[changdy]

op 表达的不清楚 .

如果是测试对需求理解的不对 .毋庸置疑是测试的问题
如果是测试随便点,出现了预期之外的结果 ,毋庸置疑不是他的问题. 可能是需求不完善.或者你没考虑的全面.


但是无论那种情况 都不值得和测试吵起来了.

[loarland]

流程有问题就把产品拉进来

[huijiewei]

测试就 2 点

1 、测试预期是否符合
2 、测试意外是否规避

看你描述的就是开发的锅。没有处理意外情况