51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师论坛测试积点免费获取渠道攻略【长期招募】博为峰网校招聘兼职讲师!横扫BAT,Python全栈测试开发技能大全
【112期】:软件测试技术哪项更吃香!中国软件测试行业现状调查报告新鲜出炉! 【杂志】做测试行业不偏科的尖子生! 自学软件测试那点事
查看: 1432|回复: 1

[转贴] 做程序员喜欢的测试人员

[复制链接]
  • TA的每日心情
    奋斗
    2020-4-8 10:48
  • 签到天数: 499 天

    连续签到: 1 天

    [LV.9]测试副司令

    发表于 2016-6-12 10:36:00 | 显示全部楼层 |阅读模式

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

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

    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、功夫在诗外

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

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

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

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

    文章出自:http://www.uml.org.cn/Test/201109145.asp

    回复

    使用道具 举报

    该用户从未签到

    发表于 2016-6-12 13:47:47 | 显示全部楼层
    看了你的这篇文章,我理解你所说的,但是做一个测试人员,文章中的有些观点还是有点不敢苟同:
    对于问题1.XX,又发现了一个严重BUG!   一个BUG导致系统两处出问题,在使用者的角度去看这两处使用都有问题那么就是两个问题,提两个BUG无可厚非,人家用户才不管你是不是一个原因引起的.要怪就怪你当初不应该产生这个BUG。
    对于问题2、我提的BUG怎么不清楚了?上次提的问题到现在都没有改!   缺陷描述不清晰确实是有些测试人员做的不对,但是开发人员在修改缺陷的时候,是否也应该和测试人员确认下不清楚的地方呢?不能说测试人员做不到位,你开发人员也做不到位。若如这样,那就半斤八两。
    对于问题3、XX,你到我这来看一下,我这测出个问题!XX,过来,又有问题。。XX,又有问题。  别说程序员了,任何人在工作的时候都不愿被打扰,这个时候就需要沟通,两者都协商好,都可以相互理解的。
    对于你说的测试人员不要机械的去验证功能和需求文档的差异。对业务和客户的了解能够帮助你更好的设计用例、定位问题。  若真按照你这样所说,那需要需求文档何用? 程序员不根据需求文档,只按照自己的想法设计程序,理所当然地认为这就是用户的需求,这样可行吗? 测试人员和开发人员再怎么熟悉需求都没有业务人员来的专业。当真的出现程序设计和需求文档不一致,那就要找业务人员商量,确认真是需求有问题,还是程序设计有问题。
    回复 支持 1 反对 0

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2020-5-27 07:32 , Processed in 0.061670 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2020 Comsenz Inc.

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