51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 21385|回复: 32

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

[复制链接]
  • TA的每日心情
    无聊
    前天 09:12
  • 签到天数: 918 天

    连续签到: 3 天

    [LV.10]测试总司令

    发表于 2014-7-2 10:00:29 | 显示全部楼层 |阅读模式
    本周的问题为“如何降低开发人员与测试人员的沟通成本?”
    此话题由会员jadeyui提供,如果你也有问题想提出来和大家一起讨论,请点击此处>>
    说不定下期讨论的问题就是由你提出的哦,请快快参与吧!




    获奖名单

    奖项

    获奖名单

    奖励

    答案链接

    一等奖

    土土的豆豆

    50元京东礼品卡

    #14
    回复

    使用道具 举报

  • TA的每日心情
    郁闷
    2015-8-20 13:16
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    发表于 2014-7-2 10:29:47 | 显示全部楼层
    有问题及时沟通,不仅仅局限于文档,会议...在平时当中遇到问题也及时沟通反馈,这些全是知识经验积累库。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    发表于 2014-7-2 14:31:10 | 显示全部楼层
    本帖最后由 许心如 于 2014-7-2 15:10 编辑

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

    使用道具 举报

    该用户从未签到

    发表于 2014-7-2 23:45:00 | 显示全部楼层
    回复 4# 许心如

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    发表于 2014-7-3 16:16:17 | 显示全部楼层
    我感觉最低的成本 就是把他拿下
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2014-7-3 18:12:48 | 显示全部楼层
    回复 9# 微微一笑la


        但是开发又不止一个,难道你一个个拿下???
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    发表于 2014-7-3 20:09:07 | 显示全部楼层
    回复 6# saramin
    哈哈,我们的见解挺一致的。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2021-8-5 10:07
  • 签到天数: 1136 天

    连续签到: 1 天

    [LV.10]测试总司令

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

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

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

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

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

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

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


    个人拙见,请指正讨论~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

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

    开发:
    1:自测
    2:接纳测试人员的意见和建议
    3:团队协作
    每个人报着一颗感恩的心,与他们共乐
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2014-7-4 17:51:08 | 显示全部楼层
    1、需求明确
    2、版本控制严格
    3、测试人员有充足的时间了解需求或有相关经验
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2014-7-7 17:17:35 | 显示全部楼层
    1、在工位位置上,可以安排相同模块的开发测试人员坐在一起
    2、需求澄清时,开发人员和测试人员都需要参加
    3、模块的开发设计方案由开发人员和测试人员功能参与完成
    4、测试用例及缺陷单要求描述清楚明白,有截图必须上传截图说明
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2017-2-13 15:06
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    发表于 2014-7-10 13:53:47 | 显示全部楼层
    1、建立在线交流平台,可以让开发人员与测试人员在线交流
    2、测试人员准确描述bug
    3、开发人员应简述开发涉及哪些功能
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2014-7-10 20:46:10 | 显示全部楼层
    有个朋友说的很到位了。。。我再补充一下: ^_^ 只谈技术上的。。。

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

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

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

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

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

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

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

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

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

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-3-29 00:17 , Processed in 0.105678 second(s), 37 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表