测试人员与开发人员沟通的正确打开方式

发表于:2017-7-11 14:22  作者:悠悠   来源:51Testing软件测试网原创

字体: | 上一篇 | 下一篇 | 打印 |我要投稿 | 推荐标签: 缺陷管理 测试管理

 测试人员与开发人员的沟通是一个永恒不变的话题,正确的打开方式就是通过最高效的手段方法,简明扼要让开发、测试都能向一致的目标努力。
  1、首先得明确需求
  测试到最后发现某模块根本没有按照需求来做,或者开发理解的不一样,这在平时项目工作中太普遍了。
  个人建议测试尽早介入需求讨论直至确定阶段,在开发和测试对于一份需求文档进行理解,人各有思,当然会产生问题。通过会议,或者直接面对面交流,可以很有效的规避两方产生的不同意见和见解。使得最终大家都朝商榷的需求去实现系统产品,完成项目。
  2. 架构设计VS用例设计
  开发在制定架构框架和主要解决方案时,测试同时开始设计用例,包括重要业务场景和复杂的逻辑流程。一般用例都是客户验收会审阅。架构也最多是研发总监、项目经理可能会过目。
  个人建议测试经理/主管对主流系统架构必须了解和掌握,可以给出自己些许小建议,降低后期维护成本。项目经理与客户等应该也审阅测试用例,给出自己想法,这样多人进行相互支持,有利于弥补缺漏。
  3. 开发编码VS测试脚本数据
  开发实现系统,写代码;同时测试人员得准备测试数据或者编写部分脚本辅助。
  个人建议测试人员多多学习白盒测试技术,这样写脚本或者准备数据时,可以不必周而复始麻烦开发人员来协助。开发人员也希望能尽可能配合测试人员,开放部分接口或者方法,加速彼此在单元测试级别的效率,即节省了来回折腾的成本。
  4. 测试缺陷度量VS开发问题汇总
  这里我把测试放前,表明这块儿是最容易产生矛盾和增加成本的节点。
  测试人员当然根据已有的规范、需求文档等对系统产品、程序,整个项目进行质量检查和控制。我们若能清理自己测试中对于问题缺陷的划分、度量,这样就能首先屏蔽那些无效的缺陷问题,减少让开发重新修复、再现问题的时间。写测试缺陷、划分测试、给予某个问题正确的优先等级,这都能有效提高项目进度,节省彼此来回反复的成本。若测试阶段都搞定了,开发能一目了然看清每个测试步骤,所用到的测试数据,能一次复现问题,那就是好的缺陷描述列表。
  另外,对于缺陷把握也适当,测试不可一股脑儿都抛给开发说有问题,除去明显需求问题外,负责人的测试可以自己去跟踪和定位问题性质。有些缺陷不是问题,也许就是个小疏漏或UI错误等,可以完全给出自己想法和建议修正点。这样开发工作会减轻,也体现了测试人员的技术含量。当然有效降低了彼此反复争议某个缺陷是否如何重现、是否能算一个问题之类的时间、精力。
  5.测试报告和结果
  问题缺陷理清楚了,测试若讲最终报告和测试结果也能详细、清晰地整理出来,让开发方面易懂,让客户和上层领导了解项目质量情况。那一份文档就可以完成所有事宜。测试方只要拿出干净的结果和报告,进行阶段汇报即可。
  个人建议根据内部规范或者行业标准,测试结果应该包括测试场景、测试方法、测试数据、测试结论等核心组成部分;报告则给出最终的评审度量总纲即可。
  6. 领导对两方的支持
  很明显一个优秀的PM或部门大佬,会有自己手段来安抚开发和测试的关系,我们开发和测试切记不是敌对找茬儿和挑刺的关系,而是一个为高质量项目、产品共同努力的优秀团队。领导在开发和测试产生重大分歧时,必须进行梳理和调节,给出自己的想法,使得大家目标统一,意见想法都一致。
  7. 个人综合素质的体现
  我最后得强调一点,不是所有开发和测试都那么理想化的,实际情况各种不同。但最终由于个人,无论是开发亦或是测试人员的综合素质,体现了其把握、沟通、交流、工作的能力。一个高级人员,能进行换位思考,能了解甚至掌握对方思想和技术,这样就可以相辅相成,合二为一,事半功倍。
  故而现在测试开发、开发测试,已经越来越模糊其界限,在技术、方法日益更新的今天,提高自身业务水平和技术能力,就可以节省各种成本。

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2017, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道