软件测试


网站首页 | 软件测试论坛 | 软件测试培训 | 软件测试博客 | 软件测试杂志 | 软件测试沙龙 | 软件测试下载 | 软件测试顾问
业界新闻 | 软件测试人才 | 软件测试技术 | 软件测试工具 | 行业软件测试 | 软件测试管理 | 软件质量专栏 | 软件开发专栏
当前位置:首页>>软件测试技术>>其他相关>>正文
测试人员应对开发人员的几个要点
文章出处:51testing论坛 作者:ananhao翻译 发布时间:2007-03-01

概述:当一个测试人员证实了程序里充满bug的时候,他是一个好的还是一个糟糕的测试人员呢?在某些开发人员看来,这是一份糟糕的工作。看上去荒谬可笑,因为项目经理等人会因产品的延期交付而责备测试人员,而且开发人员会抱怨(通常是以玩笑的形式):“测试人员对于程序过于较真。”因此很明显的,还有比计bug数更好的测试方法。这里是一些测试人员如何应对开发人员的小窍门。

当我作为一个测试人员开始我的工作时,我意识到在开发人员和测试人员之间存在一种持久的对抗关系,而且我毫不费力的相信了:这太常见了!我接受开发人员不欢迎的态度,因此我认为所有的测试人员在他们工作的不同时刻都会有相同的经历。从冷漠的不屑一顾到坦白的敌对相视(有时掩饰以同情的微笑),一个测试人员不得不忍受开发人员很多。这样很难保持测试人员积极的态度。但我们测试人员积极的态度取决于我们保持的优先权和保证项目质量的责任。我从Cem Kaner的《计算机软件测试》一书中摘得一句优美的话:“最好的测试人员不是发现了最多个bug或者使最多的开发人员感到不安的那个人,而是使开发人员fix最多bug的那个测试人员。”那么,我们从中能得到什么样的启发呢?

态度诚恳,有耐心。

作为一个测试人员,你也许发现说服一个开发人员修改你发现的缺陷比你发现缺陷本身更难。通常情况是,测试人员发现一个bug,开发人员会准备好十个理由来反驳。对于开发人员而言。有时很难接受自己的代码有缺陷这一事实——即便是另外一些人已经查明确实如此。开发人员需要测试团队的支持,他们能说服开发人员发现一个新的bug,对于尽可能使产品达到最好这一目的,是想望的、具有建设性的并且是非常重要的。采用一种人性化的方式,将更有利于测试人员了解开发人员。相信我,没有这样的一个人会和你坐在一起嘲笑他自己引出的bug。诚恳地态度常使开发人员说:“是吗?多亏你的bug报告,我得到一个非常重要的进步!”

要善用交际手段。

试着机智圆滑的展示你发现的bug并不带任何抱怨的解释它:“我肯定这是一个很小的bug,你会马上解决掉它。这是迄今为止非常完美的程序。”开发人员会非常欢迎解决它。

要善于采取心理战术,

时不时地赞美开发人员的工作。大多数开发人员不喜欢我们的bug报告的原因很简单:他们认为我们破坏了他们的辛勤劳动的成果。一些测试人员在只有发现问题的时候才与开发人员交流。对于开发人员而言,软件就像自己的孩子,而你测试人员只是一个外来的干预者。我告诉我的开发人员因为他们我才能留在公司,并且因为我,他们工作上的失误才能得以补救。这是在开发人员和测试人员之间的一种具有象征意义并且非常有益的关系。

不要使开发人员不安。

没有人喜欢别人指出自己的错误,这是人的本性。试着解释fix某个bug的具体办法,譬如需要一个大的图片,远比自顾自的提一大堆bug报告好的多。一大堆的缺陷报告不仅不能使开发人员着急,还会使你的辛苦工作在他们看来毫无用处。就像测试人员不能对程序测试完全一样,开发人员也不可能设计出没有错误的程序。他们比需要其他事情更强烈的需要测试人员的理解。我们期望出现错误,因为他们是整个过程的一部分。

有得必有失

我知道测试人员尽可能的将bug报告提的很严格。他们甚至不去听取开发人员关于这个bug不能fix或者是为了实现某个特性的解释。试着让自己放松下来,坐下来和开发人员一道分析这个bug的优先级和严重程度,如果这个开发人员对于不乐意修改这个bug有合理的和明智的解释的话,试着去理解他。只是要确保哪里是保证产品质量的底线。

警惕心理

外交手段和弹性应对并不能替换必需的警惕心理。开发人员经常找理由解释他们拒绝fix一个bug时,说因为他们没有意识到(或者你没有告诉他们)这个问题有多严重。设计你的bug报告和测试文档,使其能清楚地显示出问题的风险和严重程度。甚至更好的办法是召开一次会议,向开发人员解释这个bug。一个聪明的测试人员是一个在聆听与表达之间取得一个平衡的人。如果一个开发人员不能说服你不fix一个bug时,说服他fix这个bug就是你义不容辞的责任了。
原始链接: http://bbs.51testing.com/thread-25760-1-2.html


站内搜索
相关文章
◎我要告诉测试新手的
◎软件测试的革命三
◎软件测试的革命二
◎软件测试的革命一
◎TCL/EXPECT自动化测试脚本实例六 --- SNMP community长度测试
◎TCL/EXPECT自动化测试脚本实例五 --- 由文件中读取一行
◎TCL/EXPECT自动化测试脚本实例四 --- 批命令执行
◎TCL/EXPECT自动化测试脚本实例三 --- 全局变量
◎TCL/EXPECT自动化测试脚本实例二 --- 主程序
◎TCL/EXPECT自动化测试脚本实例一 --- telnet到目标机器
◎不太适合做测试的几种人
◎软件测试常见问题种种(一)
◎在面试中看清自己
◎追求代码质量: 通过测试分类实现敏捷构建三
◎追求代码质量: 通过测试分类实现敏捷构建二
◎追求代码质量: 通过测试分类实现敏捷构建一
◎解析测试工程师职业发展瓶颈三
◎解析测试工程师职业发展瓶颈二
◎解析测试工程师职业发展瓶颈一
◎试点项目的特点及处理方式
◎软件评测师考试经验分享
◎如何评价测试人员的工作绩效?
◎测试经理的能力要求
◎管理一个测试组织涉及到的相关概念
◎各种类型的软件的测试应该是相通的
◎MP3芯片方案
◎accessibility test的拓宽思维
◎测试人员如何获得高薪?
◎从企业问题来了解软件测试人员的作用
◎关于测试工作考核
◎测试就是不断的总结与创新
◎测试员的职责
◎从十大经典故事中学管理
◎优秀测试人员所具备的素质
◎一位软件测试工程师的工作总结
◎测试工作的未来
◎软件测试工程师的素质
◎模糊测试
◎做软件测试至少要有四种能力
◎面向对象的系统测试
◎我的SP心得
◎如何编制成功的测试计划
◎用vbs新建文件夹的方法
◎浅谈软件测试之技巧
◎微软公司是如何测试的
◎软件人员,做什么才好?
◎提高测试覆盖度
◎我从沙龙看测试界
◎软件测试职业发展的各个阶段
◎追求代码质量: 可重复的系统测试
热门文章
◎软件测试工程师面试问题选登
◎一个初级测试工程师的工作总结
◎软件测试常用术语表
◎测试人员面试三步曲
◎DOS命令大全
◎什么样的测试人员是好的测试人员
◎软件测试基本方法
◎好的测试工程师应具备的素质
◎软件测试工程师面试题
◎软件测试入门书籍(2)
◎面试官最爱问的问题背后真相
◎我在软件公司成长的三年
◎应届毕业生少走弯路的十条忠告
◎有关软件测试的术语定义集锦
◎微软的软件测试方法(一)
◎软件测试步骤
◎全景记录:软件测试工程师的一天
◎我的测试经历(1)
◎漫谈软件测试工程师的角色定位
◎谈谈对测试职业的看法
◎测试需要掌握什么
◎软件测试员自身素质培养
◎测试小技巧集锦之一黑盒测试
◎近10年最强的50本计算机图书,您读过几本?
◎软件测试人员职业发展助手
◎测试要点总结
◎如何制定成功的测试计划
◎什么是ERP,通俗版解释
◎测试的主要评测方法(1)
◎软件产品测试标准
◎测试经验交流
◎微软的软件测试方法(二)
◎编写优秀Bug报告的艺术
◎软件测试及其支持工具
◎从程序员到测试工程师
◎软件测试应遵循的八条原则
◎个人职业生涯规划发展
◎你适合做测试吗?
◎测试版本大全
◎网管和黑客都必须知道的命令
◎测试人员的挑战
◎我的测试经历(2)
◎Alpha和Beta测试简介
◎QA活动的理解与实施
◎浮躁的国内测试界—2006年测试人员招聘感悟
◎想编写出优秀技术文档,先学学这四招
◎网络最经典命令行
◎软件测试的误区
◎我的测试经历(3)
◎软件测试的心理学问题

Google提供的广告