如何降低开发人员与测试人员的沟通成本？（获奖名单已经公布）（2014.8.1）

lsekfe

本周的问题为“如何降低开发人员与测试人员的沟通成本？”
此话题由会员jadeyui提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	土土的豆豆	50元京东礼品卡	#14

ceshi81

有问题及时沟通，不仅仅局限于文档，会议...在平时当中遇到问题也及时沟通反馈，这些全是知识经验积累库。

zhyuu8208

1.拉进开发人员和测试人员的距离，比如可以坐在一片区域，有问题时方便沟通
2.每个项目组可以建立一个群，包括测试人员也在内，测试人员和开发人员可以借助这个平台做到信息共享，并能及时得到响应
3.对于缺陷，测试人员应尽量描述准确，以免因为描述不准确给开发人员造成误导，从而增大了沟通的成本

许心如

1、要有明确的需求文档，尽可能让开发人员与测试人员都能正确理解；
2、必须让开发人员与测试人员清楚他们是一个团队，合作精神才能让工作更有效率；
3、经常举办团队活动；
4、做到有问题及时反馈；5、测试人员应在三个月前找出严重的软件缺陷；
6、测试人员找到bug的心情与开发人员的心情是相反的，所以应尽量控制情绪；
等等

zhujq

回复 4# 许心如

1、要有明确的需求文档，尽可能让开发人员与测试人员都能正确理解；  ----- 补充:有条件的情况下,尽量开发与测试共同参与业务需求讨论,及设计讨论.
2、必须让开发人员与测试人员清楚他们是一个团队，合作精神才能让工作更有效率；
3、经常举办团队活动；
4、做到有问题及时反馈； ----- 补充:问题描述详尽,即"案发现场",尽力能找出问题原因,减轻开发分析.尽量确认是问题后在反馈,减少干扰;
5、测试人员应在三个月前找出严重的软件缺陷； ----- 三个月有点武断，但仍建议在动态测试前加强静态测试，发现需求及设计问题；
6、测试人员找到bug的心情与开发人员的心情是相反的，所以应尽量控制情绪；
等等

saramin

1、拿到需求文档的时候能和开发共通进行探讨和分析，有分歧的地方一定想办法统一；
2、尽量和开发在一个办公室，有问题立马沟通；
3、测试人员也要让自己提的Bug或者建议更详细，更有说服力，让开发人员认可你的能力；
4、和开发起争执的时候测试尽量克制自己的情绪，理性说明坚持自己观点的原因。

acer1841

1.组织结构上职责分明，赋予项目经理充分权力，及时传递信息，控制进度，协调关系，尤其处理好测试开发交互阶段的矛盾。
2.测试人员尽早介入项目并参与各个阶段，包括需求、设计等，对需求、设计、计划等产出物及时进行测试或评审，保证开发、测试达成一致认识，并对软件有深入的了解。
3.测试阶段，明确测试范围、依据、标准，及时评审用例及计划，及时汇报进展状态
4.要有缺陷管理规范，缺陷流程简洁完整，内容尽量详细，通过邮件等方式及时将bug通知开发
5.开发测试出现矛盾时要参考测试依据，自己无法处理则及时反馈项目经理进行协调
6.开发人员需要重视并配合测试工作，按计划提交测试，修复缺陷。

sjg1990

1、我认为测试和开发并不能分开，相对业务熟悉程度，测试人员应该比开发人员相对熟悉，更何况测试人员也应该全程参与整个项目的开发过程。
2、以项目的形式进行跟踪测试，通过横向和纵向的形式来开展沟通，横向由部门经理进行牵头，纵向由临时项目经理牵头，对开发过程以及测试过程进行有效的绩效考核。
3、纠正测试工作和开发工作的偏见。对于缺陷的形成以及开发人员和测试人员，一方面测试工作并不是为了颠覆开发人员的工作，而是打开开发人员的思路，进而使项目更加完美。这一点无论是开发人员还是测试人员都是想做的。

微微一笑la

我感觉最低的成本 就是把他拿下

xufeiping

回复 9# 微微一笑la


    但是开发又不止一个，难道你一个个拿下？？？

zcgba

我觉得这个还是要因项目而议，我是在德国从事测试行业的，德国产品的质量当然是没话说的，举几个亲身遇到的例子，参加过一个大公司的产品的测试，这个产品是别的国家的公司开发并生产的，然后产品是我和几个人测试的，这家大公司只是作为一个中间，每周开会，从我们这了解产品的问题，然后大概一个月一次再和产品开发商经行沟通，都是电话会议模式的，我们测试人员基本不参与。所以说有的项目让测试人员和开发人员坐一起不是很现实，不过我们有一点好处就是写功能需求说明的，和写测试功能说明的都是使用一个软件，我们可以看到功能说明的缺陷来告诉大公司的项目管理者，他们会和开发商谈这些问题，我们测试的产品必须安全性非常高，所以测试与开发人员不在一起讨论也是好事，否则开发人员说，这个不是错误，然后和我们测试人员解释通了，测试人员还真有可能被说服，这样是非常不好的。
还有一个例子，这次确实是个小项目，开发人员和测试人员可以直接电话沟通，项目经理在会议上起到组织协调的工作，他也参与测试的统计。
当然我这些的前提都是需求文档已经写好。总体来说对于这个题目，我觉得为了一个很好的产品，只能根据产品找到合适的沟通方式，而不是整天想着怎么省钱，有可能钱剩下来了，然后产品的问题很多。

123wowo

个人看法：
一、开发和测试的办公室位置要非常靠近，越近越好。地理决定政治。
二、测试和开发一起全程参与项目。从需求就开始，一切都要两者参与，有问题就要讨论，最后形成共识。而共识要以文档方式保存下来。
三、明确双方的共同目标。大家的目标都是要产品质量好，对产品质量负责。
四、平时双方可以开开交流会，最好是非正式的，互相听听大家的想法，各有难处，多点体谅。
五、测试人员多学点开发的知识，从开发位置去理解开发。
六、测试人员提交的bug要有效，清晰明了，帮助开发节约时间。
个人看法，难免偏颇。

123wowo

回复 6# saramin
哈哈，我们的见解挺一致的。

土土的豆豆

所谓降低成本，就是通过最高效的手段方法，简明扼要让开发、测试都能向一致的目标努力。
对于项目、产品而言，楼上基本都说了大概八九不离十。
我归纳补充一下：
1、首先得明确需求
测试到最后发现某模块根本没有按照需求来做，或者开发理解的不一样，这在平时项目工作中太普遍了。
个人建议测试今早介入需求讨论直至确定阶段，在开发和测试对于一份需求文档进行理解，人各有思，当然会产生问题。通过会议，或者直接面对面交流，可以很有效的规避两方产生的不同意见和见解。使得最终大家都朝商榷的需求去实现系统产品，完成项目。

2. 架构设计VS用例设计
开发在制定架构框架和主要解决方案时，测试同时开始设计用例，包括重要业务场景和复杂的逻辑流程。一般用例都是客户验收会审阅。架构也最多是研发总监、项目经理可能会过目。
个人建议测试经理/主管对主流系统架构必须了解和掌握，可以给出自己些许小建议，降低后期维护成本。项目经理与客户等应该也审阅测试用例，给出自己想法，这样多人进行相互支持，有利于弥补缺漏。

3. 开发编码VS测试脚本数据
开发实现系统，写代码；同时测试人员得准备测试数据或者编写部分脚本辅助。
个人建议测试人员多多学习白盒测试技术，这样写脚本或者准备数据时，可以不必周而复始麻烦开发人员来协助。开发人员也希望能尽可能配合测试人员，开放部分接口或者方法，加速彼此在单元测试级别的效率，即节省了来回折腾的成本。

4. 测试缺陷度量VS开发问题汇总
这里我把测试放前，表明这块儿是最容易产生矛盾和增加成本的节点。
测试人员当然根据已有的规范、需求文档等对系统产品、程序，整个项目进行质量检查和控制。我们若能清理自己测试中对于问题缺陷的划分、度量，这样就能首先屏蔽那些无效的缺陷问题，减少让开发重新修复、再现问题的时间。写测试缺陷、划分测试、给予某个问题正确的优先等级，这都能有效提高项目进度，节省彼此来回反复的成本。若测试阶段都搞定了，开发能一目了然看清每个测试步骤，所用到的测试数据，能一次复现问题，那就是好的缺陷描述列表。
另外，对于缺陷把握也适当，测试不可一股脑儿都抛给开发说有问题，除去明显需求问题外，负责人的测试可以自己去跟踪和定位问题性质。有些缺陷不是问题，也许就是个小疏漏或UI错误等，可以完全给出自己想法和建议修正点。这样开发工作会减轻，也体现了测试人员的技术含量。当然有效降低了彼此反复争议某个缺陷是否如何重现、是否能算一个问题之类的时间、精力。

5.测试报告和结果
问题缺陷理清楚了，测试若讲最终报告和测试结果也能详细、清晰地整理出来，让开发方面易懂，让客户和上层领导了解项目质量情况。那一份文档就可以完成所有事宜。测试方只要拿出干净的结果和报告，进行阶段汇报即可。
个人建议根据内部规范或者行业标准，测试结果应该包括测试场景、测试方法、测试数据、测试结论等核心组成部分；报告则给出最终的评审度量总纲即可。

6. 领导对两方的支持
很明显一个优秀的PM或部门大佬，会有自己手段来安抚开发和测试的关系，我们开发和测试切记不是敌对找茬儿和挑刺的关系，而是一个为高质量项目、产品共同努力的优秀团队。领导在开发和测试产生重大分歧时，必须进行梳理和调节，给出自己的想法，使得大家目标统一，意见想法都一致。

7. 个人综合素质的体现
我最后得强调一点，不是所有开发和测试都那么理想化的，实际情况各种不同。但最终由于个人，无论是开发亦或是测试人员的综合素质，体现了其把握、沟通、交流、工作的能力。一个高级人员，能进行换位思考，能了解甚至掌握对方思想和技术，这样就可以相辅相成，合二为一，事半功倍。
故而现在测试开发、开发测试，已经越来越模糊其界限，在技术、方法日益更新的今天，提高自身业务水平和技术能力，就可以节省各种成本。


个人拙见，请指正讨论~

Minnie_

组织者：
1：从需求评审阶段尽量让测试人员参与和发言（测试可以了解产品内部架构全面测试，同时对于开发者测试的思想和思维可以影响开发）。
2：定期组织开发和测试讨论。
3：拉进开发人员和测试人员的距离。比如工位在一起。
4：组建信息共享平台，有问题及时响应。比如建立群。
5：经常举办团队活动。
6：营造良好的工作环境，爱惜自己的员工，承担责任。

测试人员：
1：bug清晰描述
2：有问题及时响应
3：多学习，提高自身的技能
4：团队协作
​
开发：
1：自测
2：接纳测试人员的意见和建议
3：团队协作
每个人报着一颗感恩的心，与他们共乐

sd107880

1、需求明确
2、版本控制严格
3、测试人员有充足的时间了解需求或有相关经验

seal_wk

1、在工位位置上，可以安排相同模块的开发测试人员坐在一起
2、需求澄清时，开发人员和测试人员都需要参加
3、模块的开发设计方案由开发人员和测试人员功能参与完成
4、测试用例及缺陷单要求描述清楚明白，有截图必须上传截图说明

LWZ88

1、建立在线交流平台，可以让开发人员与测试人员在线交流
2、测试人员准确描述bug
3、开发人员应简述开发涉及哪些功能

lulu2000

有个朋友说的很到位了。。。我再补充一下： ^_^ 只谈技术上的。。。

一.项目整体管理应该规范，需求分析、概要设计、详细设计、编码、测试等各个环节都要有里程碑、并且能有规范的文档，每一个里程碑环节，开发、测试以及项目管理的PM等、都要共同参与技术文档的评审，并发表修改意见、直到对文档的修改意见达成一致。

二.项目进展中的各个环节，都要参照公司技术规范来做事、PM、开发、测试等不以职位轮事，做事的出发点都放在项目整体的质量上，一环环的协作推进项目。比如：

1、首先得明确需求 --->[ 开发和测试一起参与评审、达成一致意见。]
测试到最后发现某模块根本没有按照需求来做，或者开发理解的不一样，这在平时项目工作中太普遍了。
个人建议测试今早介入需求讨论直至确定阶段，在开发和测试对于一份需求文档进行理解，人各有思，当然会产生问题。通过会议，或者直接面对面交流，可以很有效的规避两方产生的不同意见和见解。使得最终大家都朝商榷的需求去实现系统产品，完成项目。

2. 架构设计VS用例设计 --->[ 开发和测试一起参与评审、达成一致意见。]
开发在制定架构框架和主要解决方案时，测试同时开始设计用例，包括重要业务场景和复杂的逻辑流程。一般用例都是客户验收会审阅。架构也最多是研发总监、项目经理可能会过目。
个人建议测试经理/主管对主流系统架构必须了解和掌握，可以给出自己些许小建议，降低后期维护成本。项目经理与客户等应该也审阅测试用例，给出自己想法，这样多人进行相互支持，有利于弥补缺漏。

3. 开发编码VS测试脚本数据----> [开发和测试一起参与评审、达成一致意见。]
开发实现系统，写代码；同时测试人员得准备测试数据或者编写部分脚本辅助。
个人建议测试人员多多学习白盒测试技术，这样写脚本或者准备数据时，可以不必周而复始麻烦开发人员来协助。开发人员也希望能尽可能配合测试人员，开放部分接口或者方法，加速彼此在单元测试级别的效率，即节省了来回折腾的成本。

4. 测试缺陷度量VS开发问题汇总----> [测试人员、提交软件缺陷（bug）时，对问题的重现步骤的描述一定要详尽，最好能附加问题所在的图片，使得问题重现一目了然。一定要让开发能很容易重现。]

这里我把测试放前，表明这块儿是最容易产生矛盾和增加成本的节点。
测试人员当然根据已有的规范、需求文档等对系统产品、程序，整个项目进行质量检查和控制。我们若能清理自己测试中对于问题缺陷的划分、度量，这样就能首先屏蔽那些无效的缺陷问题，减少让开发重新修复、再现问题的时间。写测试缺陷、划分测试、给予某个问题正确的优先等级，这都能有效提高项目进度，节省彼此来回反复的成本。若测试阶段都搞定了，开发能一目了然看清每个测试步骤，所用到的测试数据，能一次复现问题，那就是好的缺陷描述列表。
另外，对于缺陷把握也适当，测试不可一股脑儿都抛给开发说有问题，除去明显需求问题外，负责人的测试可以自己去跟踪和定位问题性质。有些缺陷不是问题，也许就是个小疏漏或UI错误等，可以完全给出自己想法和建议修正点。这样开发工作会减轻，也体现了测试人员的技术含量。当然有效降低了彼此反复争议某个缺陷是否如何重现、是否能算一个问题之类的时间、精力。

5.测试报告和结果
问题缺陷理清楚了，测试若讲最终报告和测试结果也能详细、清晰地整理出来，让开发方面易懂，让客户和上层领导了解项目质量情况。那一份文档就可以完成所有事宜。测试方只要拿出干净的结果和报告，进行阶段汇报即可。
个人建议根据内部规范或者行业标准，测试结果应该包括测试场景、测试方法、测试数据、测试结论等核心组成部分；报告则给出最终的评审度量总纲即可。

6. 领导对两方的支持
很明显一个优秀的PM或部门大佬，会有自己手段来安抚开发和测试的关系，我们开发和测试切记不是敌对找茬儿和挑刺的关系，而是一个为高质量项目、产品共同努力的优秀团队。领导在开发和测试产生重大分歧时，必须进行梳理和调节，给出自己的想法，使得大家目标统一，意见想法都一致。

7. 个人综合素质的体现
我最后得强调一点，不是所有开发和测试都那么理想化的，实际情况各种不同。但最终由于个人，无论是开发亦或是测试人员的综合素质，体现了其把握、沟通、交流、工作的能力。一个高级人员，能进行换位思考，能了解甚至掌握对方思想和技术，这样就可以相辅相成，合二为一，事半功倍。
故而现在测试开发、开发测试，已经越来越模糊其界限，在技术、方法日益更新的今天，提高自身业务水平和技术能力，就可以节省各种成本。

tatsujin

大家使用统一的流程管理工具，比如jira，QC等，把所有的需求、设计、用例、缺陷、报告都放到上面方便大家沟通与查找。
还有即时聊天工具也是不可或缺的。
从实际来说，很多时候需求不会描述的那么详细，需求和开发为一个bug的分歧应该有一个总负责人才行，要不没有依据的情况下争执会无休止而且无意义。