51Testing软件测试论坛

标题: 如何降低开发人员与测试人员的沟通成本？（获奖名单已经公布）（2014.8.1） [打印本页]

作者: lsekfe 时间: 2014-7-2 10:00
标题: 如何降低开发人员与测试人员的沟通成本？（获奖名单已经公布）（2014.8.1）
本周的问题为“如何降低开发人员与测试人员的沟通成本？”
此话题由会员jadeyui提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

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

作者: ceshi81 时间: 2014-7-2 10:29
有问题及时沟通，不仅仅局限于文档，会议...在平时当中遇到问题也及时沟通反馈，这些全是知识经验积累库。

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

作者: 许心如 时间: 2014-7-2 14:31
本帖最后由许心如于 2014-7-2 15:10 编辑

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

作者: zhujq 时间: 2014-7-2 23:45
回复 4# 许心如

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

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

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

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

作者: 微微一笑la 时间: 2014-7-3 16:16
我感觉最低的成本就是把他拿下

作者: xufeiping 时间: 2014-7-3 18:12
回复 9# 微微一笑la

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

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

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

作者: 123wowo 时间: 2014-7-3 20:09
回复 6# saramin
哈哈，我们的见解挺一致的。

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

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

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

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

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

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

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

个人拙见，请指正讨论~

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

测试人员：
1：bug清晰描述
2：有问题及时响应
3：多学习，提高自身的技能
4：团队协作

开发：
1：自测
2：接纳测试人员的意见和建议
3：团队协作
每个人报着一颗感恩的心，与他们共乐

作者: sd107880 时间: 2014-7-4 17:51
1、需求明确
2、版本控制严格
3、测试人员有充足的时间了解需求或有相关经验

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

作者: LWZ88 时间: 2014-7-10 13:53
1、建立在线交流平台，可以让开发人员与测试人员在线交流
2、测试人员准确描述bug
3、开发人员应简述开发涉及哪些功能

作者: lulu2000 时间: 2014-7-10 20:46
有个朋友说的很到位了。。。我再补充一下： ^_^ 只谈技术上的。。。

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

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

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

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

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

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

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

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

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

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

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

作者: 酷狗 时间: 2014-7-14 11:34
提高开发人员的测试概念
提高测试人员bug描述细致能力，以及了解开发。

作者: kevin09060 时间: 2014-7-14 13:30
　认识沟通成本
　　沟通是必须的，但是沟通存在“巨大”成本。这个成本表现在：
　　1. 沟通无法实现100%的信息传递，由于信息失真导致的成本。
　　2. 沟通本身存在的时间和空间成本。
　　3. 由于一次沟通不到位，导致发生后续多次沟通。
如何降低开发人员与测试人员的沟通成本？
　　1. 选择正确的沟通途径。
　　选择正确的沟通途径对于确保完成沟通目标起到非常重要的作用。在软件项目管理中，存在各种各样的沟通。可能因为沟通的对象不同，也可能因为沟通的内容不同，我们可能需要选择不同沟通途经。最有效的是face to face的沟通，特别是在需求评审阶段。
　　2.使表述的内容易于理解。
　　沟通的困难往往在于无法把想要讲述的内容以一种对方容易理解的方式呈现给对方。作为测试人员，bug的描述一定要清晰，主题要简明扼要，场景步骤要描述清楚比如测试帐号，数据，以及重现的步骤。
　　3. 沟通技巧。
　　作为测试人员一定要在明确自己的立场（保障项目质量和用户需求）的同时，注意和开发同学沟通的方式方法。有问题先要很好的沟通，必要的时候可以从他们的立场出发去寻求突破，不要轻易破坏和开发之间的友好关系，但是在问题得不到解决，或者会直接影响到项目的进度及质量的时候，也要果断的向上一级寻求帮助，让更有发言权的人来作出沟通和确定。

作者: zhconnie 时间: 2014-7-16 16:49
回复 14# 土土的豆豆

还真是条文性很好的拙见，拙读了。。

作者: zhconnie 时间: 2014-7-16 16:54
清晰明确的需求文档、bug提交时条理清晰的描述问题，以便bug能重现、沟通及时，如建立一个交流群，便于问题告知，明确，这些足以，至于要不要凑到一块坐，看空间允许与否吧。。。实在坐不下就不要去摞摞了，毕竟大热天滴，也不利于通风。。。

作者: 土土的豆豆 时间: 2014-7-17 09:50
回复 23# zhconnie
这个是讽刺偶滴意思么~咔咔
欢迎批评

作者: 土土的豆豆 时间: 2014-7-17 10:21
回复 19# lulu2000
补充得不错~

作者: 2009052122 时间: 2014-7-22 16:04
回复 1# lsekfe

交流模式可以多样化:
可以借助即时交流工具交流即时问题;
可以借助问题汇总,经验汇总等文档蓄积知识宝库,供后来人学习了解,避免冗余问题的时间耗损

作者: testdc 时间: 2014-7-31 21:40
我是来学习的哈哈

作者: ddwl2012 时间: 2014-8-21 14:42
1.需求理解:共同参与
2.需求变更:邮件共同通知
3.用例评审:共同参与
4.对争议缺陷共同讨论并定结果
5.测试轮次结束后，及时总结沟通,制定改进方法并执行

作者: Miss_love 时间: 2014-8-22 16:34
回复 14# 土土的豆豆

土豆V5

作者: skchao1111 时间: 2014-11-3 14:17
ding，谢谢！

作者: 海里的幸福 时间: 2016-10-28 15:51
我顶啊。接着顶

作者: 海里的幸福 时间: 2016-10-31 17:36
震撼！!!!!!!!!!

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)