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

[wx497657341]

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

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

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

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

[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 都是测试在探索未定义行为时候发现的问题。