今天跟测试同事大吵了一架，现在心里特别不是滋味，忍不住想问问大家：开发和测试之间真的只能是针锋相对的关系吗？
事情是这样的，我是一名开发，最近刚把一个功能部署到测试环境。本以为能顺顺利利推进测试流程，结果测试同事在测功能的时候，感觉根本没吃透需求文档，操作的时候完全是凭着自己的理解 “瞎点”。有些功能逻辑需要特定的前置条件才能触发，他没按正常流程走，最后没得到预期的数据，二话不说就直接提了个 bug 。
我看到 bug 描述的时候有点无奈，就跟他说：“这个功能的逻辑在需求里写得很清楚，建议先把需求吃透再测，不然很容易误解功能设计。” 结果这话一出口，他立马就不爽了，觉得我在质疑他的工作能力，两个人你一言我一语就吵了起来。
其实我完全没有针对他的意思，毕竟开发和测试的目标都是让产品更完善。但这种因为需求理解不一致引发的冲突，真的太影响工作效率了。想问问大家，平时开发和测试之间都是怎么沟通协作的？遇到这种需求理解偏差的问题，该怎么解决才不会伤和气呢？
 |
101
feller 6 天前 via iPhone
你的接口只返回成功的情况吗，不返回异常的 code 嘛
|
 |
102
shawnsh 6 天前 via Android
在过去工作经验中，很多开发和测试遇到的问题，追溯源头，都是产品带来的。抛开人的问题，应该是新功能和旧的框架融合的问题。功能越多，越容易出错。功能很大部分决定了后续事情的发展，后面的人只能在沼泽地里改善，有经验的人会一开始就不接那个功能
|
 |
103
wintersun 6 天前
开发，应该参与测试用例的评审，并把测试用例作为自己的工作输入之一！
|
 |
104
cobbage 6 天前 via Android
心态得变下。内部系统你这还可以，放网上大家用的不要相信用户的操作。
|
 |
105
IamUNICODE 6 天前
测试就是干这个的，要是是需求问题，拉上产品吵，别的你就打哈哈改好了，哪有程序没 bug 的，早点发现在测试阶段大家都开心（前提大家都是正常人）
|
 |
106
99185302 6 天前
要是测试没提 BUG ，到了用户端出了问题的话，估计就变成 SB 测试这种 BUG 都测不出来。
|
 |
107
wolfie 6 天前
跟人的沟通意愿有关系，语言本来就是 你一句我一句的，有些人脑子就是笨，听不懂就把自己的逻辑一直重复讲，不听别人说话。
还有能不能拎的清边界。 |
 |
108
yufeng0681 6 天前
你和他平级，吵架很正常。
就问题单来说，有个项目经理应该审核一下问题单的质量。 如果剩下了这个审核角色，直接流到你这边。 那必须有个回溯质量的过程，无效问题单数要能影响他绩效才能扼制浪费研发时间的事情发生。 [至少他应该来和你先沟通，后提单] |
 |
109
jheroy 6 天前 via iPhone
你这有点生在福中不知福啊，我都是让测试没事多跑跑，尽量跑出问题来。
|
 |
110
mon6912640 5 天前
哥们儿，你刚毕业吧？
|
 |
112
zhuawadao 5 天前
看你语气"需求写到很清楚，建议先把需求吃透"，这句就是在找着吵架。如果是当众说的，那必超无疑。和开不开发，测不测试没有关系。和你的措辞有关系。就像你对炸油条的说，先把油条炸明白再出来摆摊一样。
|
 |
113
udisyue 5 天前
测试能这么理解这么点，说明用户也能这么点，改你的 bug 去吧
另外，你沟通方式太差了，觉得不是问题就不是问题，双方达不成一致找产品判断去，不要预设立场别人有问题。要记住，测试跟你是一个线的，不管最后这个有没有问题，你们是一起来提升质量的 |
 |
114
Shazoo 5 天前
测试是给你兜底的，友军。
你不认可 bug 请去找产品。 感觉丢了面子建议读下菜根谭。 |
 |
115
xuanbg 5 天前
因为用户是不会按产品设计的逻辑来操作的，所以测试做的没错。你要做的修补是：如果输入不符合产品设计的逻辑，那么就告诉用户需要怎么去做才会得到预期的结果。
|
 |
116
jjwjiang 5 天前
先回答你的问题，开发和测试应该是一伙的
再指出你的问题，是你一开始没把他当一伙的所以才引发了争执 |
 |
117
worldhandsomeboy 5 天前
牛逼，竟然把未交付的业务挂网上，再次说明你的幼稚
|
 |
118
liqingyou2093 5 天前
有问题修改优化一下不挺好, 测试都用不明白 ,客户能用明白吗
|
 |
119
chenyu0532 5 天前
这个时候你俩就可以拿着产品文档去找产品了，你俩吵个什么劲。
谁理解错了谁买奶茶，既能解决问题，还能增进同事友谊。 以后有改不改都无所谓的东西，测试就不会让你改。 |
 |
120
MrEhco 5 天前
需求评审，开发文档评审，测试用例评审大家都认账了哪来这么多事呢
|
 |
121
poorcai 5 天前
@SoviaPhilo #21 我前司就是这么操作的
|
 |
122
ajan 5 天前
建议楼主搜索看看：
The Square Hole Drink Water User Friendly |
 |
123
Martens 5 天前
感觉楼主本身就对测试不爽，这次没忍住说出来了。感觉楼主沟通方式有问题
|
 |
124
nenseso 5 天前
搞清楚谁是你的朋友，谁是你的敌人
|
 |
125
chouxiang99 5 天前
测试除了正常的流程要点 更重要的就是异常测试啊 前置没有完成的情况下 去进行下一步操作 系统肯定要娄底的 还有一个 这种你觉得不算是 bug 的情况 直接转给产品 让产品看看 再一个 你们有没有考核 bug 的 kpi 如果没有 那你纠结啥 提就是咯
|
 |
126
yongzhenchen682 5 天前
合格的测试没问题，需求有问题，应该先评估一遍需求，在评估一遍测试场景，自己开发过程的业务逻辑明显感觉不合理也要提出来不要闷头开发。
|
 |
127
iyaozhen 5 天前
我是测试，应该能说两句
肯定不是水火不容的嘛，但改吵还得吵，前面也有人提了，拉上 PM 一起吵。也不用说什么“没有质疑他工作能力”，其实就是直接点，就是质疑你。我遇到一个研发负责人，就是只说这个项目很重要，我投入的都是 p8 级别的人力，你不要整几个 p5 的 QA 配合。 当然机制也还是要的，虽然大家都不喜欢度量，但绝对异常的数据还是值得关注，比如你这个场景可以定义一个“有效 Bug 比率”，数据特别差 乱提 Bug 肯定不行。 不过前面还是楼主一方之言，难道之前测试 case 没有评审？是没有计划测哪儿算哪儿？还是测试用例的一部分即使“不符合”需求，也是异常测试，有时候我们还要专门组织 ET 测试。提的这个 Bug 是项目前期还是后期（对于 QA 有要求，重要 Bug 需要今早发现，先测主流程），还是回到前面的，有没有测试计划？ |
 |
128
abbq 5 天前
@SoviaPhilo #21 前司的领导就是这么做的，最后是真的导致开发和测试水火不容，每天各种争吵；另外一个就是把代码量作为考核指标，后面大家都在堆代码量，甚至复制无用的代码进去，后面屎山到无法维护的地步了
|
Select Language