51Testing软件测试论坛

标题: 好久没来了,冒个泡! [打印本页]

作者: chrisgardner_    时间: 2013-7-5 16:49
标题: 好久没来了,冒个泡!
一、 对待自己。
在我接触过的同事中,很多都有这么一种打算:先从测试做起,然后几个月后打算申请到开发。诚然,在中国作坊式的软件开发大环境下,确实测试职位给人的只有迷惘,而转到开发也实属无奈,抱着一种身在曹营心在汉的心态进行工作,那么你将连测试究竟做什么的也都不清楚,更别说开发的。如果你没有打算在该职位上兢兢业业工作半年以上,那么我建议你离职。
二、 对待职位
可能很多人都了解目前的测试员生存状况,我也不瞒你的说一句,这话很真的“当有项目验收了,开发员和项目实施组必然居功至伟;当出现问题的时候,测试员定然是责无傍贷!”但你没必要去理会这个,因为这个你管不了,你只需要在其位,谋其职!并且真的出现大问题,本身对你也是一个耻辱。中国人越来越有钱了,买什么都冲着品牌,而质量恰恰是品牌的前提,你把一件质量的事情做好,那么你的质量意识也就确立了,至少懂得了优质质量带给你的享受。
三、 对待工作
1、 你要了解整个行业流程。刚开始做测试的同时很多都在做黑盒测试,而黑盒测试往往对代码编写能力要求不是很高,这样给刚入门的人就造成了一个测试人员不需要太多知识的误解。然而,做测试往往需要很广泛的知识。不仅仅只是专业上的,而且要了解很多开发人员不了解的东西,在一个系统里面开发人员可以只了解客户需求,而你需要了解整个全局的东西。呵呵,感觉有点统筹全局的成就感。不过有时候相对于开发人员来说也的确是这样的。开发人员可以不用太多了解用户的需求,而你却需要能够准确捕获用户的观点,对很多细节需要非常注意。
2、 你需要具备很好的沟通能力:沟通是人类相互进步的一个重要标志,用在这个行业里面沟通也比较适用。你的沟通往往不仅是跟开发人员的沟通,有时候也会跟你的客户进行沟通的。这是两种不同类型的人,他们关心问题的侧重点也不同。所以你沟通时候需要掌握一定的技巧,这样才能从客户那儿得到比较准确的需求。有时候你的工作会被开发人员认为是“破坏”性的工作,这样就会引起你跟开发人员的冲突,所以当你发现一个bug之后如何跟开发人员沟通也是一门艺术。很多时候你不仅仅是把bug写出来,也要很好地说给开发人员知道。从而达到你彼此想要的一种结果。
3、 你需要具备很好的自信心:很多时候开发人员会经常认为测试人员的开发相关知识不如自己,所以会有一种轻视的态度,这个时候你除了补充你的专业知识之外还需要有很强的自信心。呵呵。如果允许他对你说这说那,那么我认为你的工作还没开展就已经处在十分不利的地步了,你将会被他们牵着鼻子走。这种现象很正常。而我却属于那种很讨厌被别人牵着鼻子走的人。所以我知道你一定要很专业才能让别人尊重自己的劳动成果并听取自己的见解。当然这种自信心也是建立在心平气和下的沟通,不是完全对立的。Cem Kaner在《Testing Computer Software》书中有一段话: “The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed.” (最好的测试人员不是发现最多BUG或是使得最多开发人员不自在的人,而是能够[说服开发人员]修正最多BUG的人),你应该好好地理解这句话。
4、 你需要保持一种怀疑的精神:你会经常碰到这样一种情况,你往往发现的bug交给开发人员时他们总是尽他们最大的努力解释每个他们认为不是bug的bug。你在倾听他们解释的同时必须要怀疑他们的观点直到你自己确认过之后。
5、 你需要耐心和很好的记忆力:有时候往往一个bug需要你很耐心的花费时间、精力去投入在上面,而且当你再找到有些类似的bug的时候,要能从脑子里面找出来这些bug,这就需要你有很好的记忆力。其实如果不具备这些条件了那么相关的文档就是你最好的查询资料。
6、 你需要一颗安静的心:因为浮躁的人是找不出隐藏在深处的bug的,所以当你测试的时候你应该保持内心的平静,这样你才会保持很好的洞察力来找到那些隐藏很深的bug。而且也会抓到相关的重点的。这点是很重要的。否则你的测试跟流水账做也没什么区别,根据业务流程,根据用户需求,根据开发人员的思路一路跑下去,发现一些皮毛的bug。这不是一个好的测试人员应该做的。你在平静当中才能保持自己的观点不被别人左右。
7、 你还需要能够承受压力并排遣压力:无须质疑,你的工作承受着一定的压力,当然这样说有点片面,不过大体上应该是这样的。所以你经常承受着一定的压力,客户在催促,开发人员在delay,风箱里面的老鼠两头受气。所以你要能够承受压力,包括外界的、工作上的压力。并且不要把因为压力而导致的不好的情绪带到工作当中。学会排遣这些压力,保持一颗轻松的,平静的心,然后全身心投入到你的工作。
四、 对待自动化测试工具
不要认为自动化测试工具能带给你质的飞跃,毕竟使用的方式千差万别的,不是能用编程写死的一个规则排查出所有BUG,至少在《铝业专家》身上是绝对走不通的。我曾经以为自动化测试就能解决日益繁重的测试任务,然而开发的不规范性,版本的多样性,客户需求巨大差异性,都一一影响自动化的脚本运行,并且由于脚本的单一和维护脚本的时间周期长度,出来的效果往往华而不实,十分表面。君不见,神五载的是真人,而非机器人。最好测试效果是能搭建与用户完全相同的测试环境和操作方式。
作者: forstkksk    时间: 2013-7-5 23:22
受教了,感谢
作者: 赵佳乐SMILE    时间: 2013-7-8 09:24
通常都是被开发说服。。。
作者: chengning    时间: 2013-7-9 17:15
我们现在把很容易被开发说服的 也说成工作态度问题
作者: chengning    时间: 2013-7-9 17:16
我们现在把很容易就被开发说服的  也做为一种态度问题  是不是很蛋疼了
作者: 没翅膀的飞鱼    时间: 2013-7-9 22:26
介绍的很中肯,受教了
作者: ChelyFang    时间: 2013-7-10 09:10
哈哈,好喜欢你说的"要有一颗平静的心",每次开发解释bug,我反驳的时候,就有那种要吵起来的感觉,很讨厌那种,这个毕竟是工作,工作跟生活应该完美的分开,不要把个人的情绪带到工作中,就事论事才是王道!有时候情绪也会被开会莫名的带走.......
作者: 夕阳西下°    时间: 2013-7-12 09:13
楼主写的很好,对待测试工作不仅仅需要具备全面的专业知识,心态同样也很重要
作者: 千里    时间: 2013-7-12 16:39
身在曹营心在汉,哎。
作者: chrisgardner_    时间: 2013-7-13 08:50
回复 3# 赵佳乐SMILE
只要你认定了这是问题,立场要坚定,迟早真理会站在你这边!
作者: chrisgardner_    时间: 2013-7-13 08:50
,,,
作者: chrisgardner_    时间: 2013-7-13 08:51
好吧,我没有遇到过!回复 5# chengning
作者: chrisgardner_    时间: 2013-7-13 08:51
回复 7# ChelyFang
共勉!
作者: chrisgardner_    时间: 2013-7-13 08:51
回复 9# 千里
千里哥哥,好(ˇˍˇ) 想~你啊,好记的我么!
作者: chrisgardner_    时间: 2013-7-13 08:53
回复 9# 千里
为什么之前加了你q现在找不到了,呜呜!~~!~
作者: rrene    时间: 2013-7-13 10:30
回复 15# chrisgardner_


    很明显被t了,这都要问 ,智商堪忧
作者: 赵佳乐SMILE    时间: 2013-7-15 16:50
回复 10# chrisgardner_


   恩
  上个项目有个 上一步 下一步的按钮  上一步没有背景颜色 下一步有背景蓝色
  我就提了个bug 这个bug fix-reopen fix -reopen
  后来我问开发 怎么回事 到底改没改
  开发给我来一句 客户就这么要求的
作者: 千里    时间: 2013-7-16 12:42
回复  chrisgardner_


    很明显被t了,这都要问 ,智商堪忧
rrene 发表于 2013-7-13 10:30



    哈哈,还拉进黑名单了。
其实没有,只是时间久远,长时间没有联系,没印象了。
作者: 千里    时间: 2013-7-16 12:42
回复  chrisgardner_


   恩
  上个项目有个 上一步 下一步的按钮  上一步没有背景颜色 下一步有背景 ...
赵佳乐SMILE 发表于 2013-7-15 16:50



    如果能够抓到客户,这问题还算好解决。如果客户对于测试是隐形的,那测试其实很悲剧。
作者: chrisgardner_    时间: 2013-7-16 13:55
回复 16# rrene
有点情怀好不好,情怀,懂吗?
作者: 赵佳乐SMILE    时间: 2013-7-16 14:09
回复 19# 千里


    抓不到 在那8个月  连客户的影子都没看到




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2