分享到
做程序员喜欢的测试人员
 
发布于2011-09-14
 

程序员与测试在工作流中是上下游的关系,而且工作上联系紧密,沟通上难免出现各种各样的问题。笔者作为管理软件行业的一个程序员,也算是和测试人员打过多年交道。希望能从程序员的角度出发,为测试人员提一点建议。

首先,我们一起来看一下程序员们最不愿意从测试人员口中听到哪些话?

1、XX,又发现了一个严重BUG!

(尼玛,文案错误也要算C级BUG吗?尼玛,1号BUG和2号BUG是同一个问题,你提两遍C级?要不要哥把你提的BUG在JIRA里都置成Not a BUG)

2、我提的BUG怎么不清楚了?上次提的问题到现在都没有改!

(尼玛,你提的BUG里面,截图有木有?操作环境有木有?好容易写点文字描述又不加标点!有木有!我只能按我自己的理解改喽!)

3、XX,你到我这来看一下,我这测出个问题!XX,过来,又有问题。。XX,又有问题。

(泪。。能不能让哥安安静静写2个小时的程序,程序员很忌讳碎片化的时间,思路都木有了啊。。又要重新想啊。。)

开发和测试是项目进程中至关重要的两个环节,程序员与测试人员若能相亲相爱,一定是PM们最愿意见到的事情。然而不同角色的人员在共同完成项目的过程中,实现天衣无缝的合作总是很有挑战的事情。诚然,这些挑战可能是由于参与人员的能力问题,这无可避免。但我更愿意相信,沟通不畅、习惯不佳、缺乏换位思考等因素才是最常见的。测试人员在实际的工作中如果能够注意以下内容,相信一定会成为程序员喜欢的测试。

1、份内之事做到专业

提交BUG要描述清楚。注明操作步骤、测试环境、描述清楚正常现象和BUG现象的差异。

BUG级别设定不要全凭主观看法,应该和产品、开发人员沟通后,确定一套评价标准,客观评估。

尽量避免提出重复BUG,两个不同页面的相同问题应归为一个BUG的两次出现。更深层面的相同BUG原因,可以多和工程师沟通了解。

2、沟通之中互相理解

最终程序员的工作方式,不要一发现问题就找程序员,编码过程中思路被打断对程序员来说是很痛苦的事情。可以收集多个问题后统一找程序员处理,或是在即时通讯工具上留言,看程序员的时间安排,给他几分钟时间缓冲,在其方便的时候沟通。

测试最怕“Not a BUG”,程序员怕的是“C级BUG”和“重开”。设C级和置重开时慎重一些,不确定的可以先和程序员沟通过再提。

3、功夫在诗外

熟悉业务、了解客户,对于测试人员来说也是非常重要的。测试人员不要机械的去验证功能和需求文档的差异。对业务和客户的了解能够帮助你更好的设计用例、定位问题。

多和程序员沟通,了解开发思路。了解开发思路能够帮助测试人员找到测试步骤的盲点,更容易测出真正的问题。这样的沟通,也会帮助开发人员检验开发思路的正确性,更好的提高项目团队的效率。

如果项目团队里有一个这样的测试人员,任何一个离开项目的程序员都会怀念他的。

当然,程序员们也不能被惯坏了,一味的要求别人如何配合自己。在项目中换位思考,互相理解也同样是程序员应该注意的事情。做相亲相爱的一家人,才能携手并肩,一起向前!


 
相关文章

由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
 
相关文档

统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
 
相关课程

IT安全原理、框架与实践
ITIL认证
ITIL Foundation认证培训(ITIL V3 Foundation )
IT规划体系与实践


史蒂夫·乔布斯的脑子里在想什么
写给我们这些浮躁的程序员
如何使用搜索技巧来成为
IT部门在信息化中的角色转变
支撑软件开发人员的三种精神
小强爬行记
更多...   


统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行

相关咨询服务
基于CMMI2-3过程改进咨询
软件开发过程


中国移动通信 网络规划与管理
某航空公司 IT规划与企业架构
某金融公司 IT服务管理(ITIL V3)
中国联通集团 IT前沿知识概述
中海油 企业IT架构设计
更多...   
 
 
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号