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

lsekfe

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

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

海里的幸福

震撼！!!!!!!!!!

海里的幸福

我顶啊。接着顶

skchao1111

ding，谢谢！

Miss_love

回复 14# 土土的豆豆


    土豆V5

ddwl2012

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

testdc

我是来学习的 哈哈

2009052122

回复 1# lsekfe


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

土土的豆豆

回复 19# lulu2000
补充得不错~

土土的豆豆

回复 23# zhconnie
这个是讽刺偶滴意思么~咔咔
欢迎批评

zhconnie

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

zhconnie

回复 14# 土土的豆豆


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

kevin09060

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

酷狗

提高开发人员的测试概念
提高测试人员bug描述细致能力，以及了解开发。

tatsujin

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

lulu2000

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

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

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

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

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

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

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

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

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

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

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

LWZ88

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

seal_wk

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

sd107880

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

Minnie_

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

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

土土的豆豆

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

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

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

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

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

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

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


个人拙见，请指正讨论~