51Testing软件测试论坛

标题: 我也谈谈我对测试职业的看法 [打印本页]

作者: 肥肥兔    时间: 2009-7-2 12:59
标题: 我也谈谈我对测试职业的看法
已经很久没来51testing了。在测试行业做到今天。虽然已经是个小主管。但是现在对测试行业已经没有什么感觉了。。怎么说呢。。。我觉得这几年软件行业始终没有怎么发展起来,尤其是测试行业,我觉得这几年都是停步不前的。呵呵,可能我这里是个小地方。看得比较肤浅。就拿我的经历来说吧,一直在这个小城市生活,测试行业不是我一直的职业,是在前几年转的,因为以前从事的技术支持行业跟测试行业有些衔接,转行倒也轻松。转行后那段时间,确实学了很多东西,包括知道了软件业也是有一定规范遵循的,还有N多的测试方法和测试技术。。。这些都是受益匪浅的,后来转进现在的这家公司,真是让我了解了软件业中的一些极端。现在的测试环境,几乎就是个小作坊式环境。而且由于测试不被重视的状态一直延续,至今整个公司都没能形成一种对软件质量高度重视的态度
   呵呵,这不是发牢骚,是我真实的感受,不过可能也影响我做出一些决定。待了几年后,我现在决定慢慢的退出这个行业。从我如这一行到现在,一直以来周而复始的问题每时每刻都在循环。都是不变的。
   比如说研发吧。我想很多测试人员都有同感的。研发人员的程序写的不咋的,各个都挺牛,我这个公司就是。记得我刚刚进这个公司。公司的软件连安装程序都没有,至于一些异常的低级错误,就更多了。测试就像没有,因为程序员改了什么就直接扔出去。测试从来不知道。呵呵,出了问题,就找测试来了。搞得我一头雾水。我记得很清楚的一个事情。我们有个软件拿出去给客户试用。之前因为软件的BUG太多,花了一周加班加点测试修改(好不容易改了个勉强能DEMO的版本),然后发版了。过了几天对方反馈出错了,老板发火了。然后大家就找测试的原因。说我们怎么没测到。我没有说什么。跑去测试环境验证,发现根本没有这些错误,然后一再追问程序员,说是中途修改了程序直接发出去的。我火了。当时就质问他改了为什么都不吭声。那时我就觉得为什么是这样的协作呢?呵呵,今天看起来,这些都是小CASE,因为后面这几年遇到的极端的事情比这个厉害多了。
   在一个新公司,如果什么都没有建立的情况下,你想推行一些规范,是需要上层的高度支持的。这里也是一样。总之我在公司里推行的一些流程,总是被间接的破坏。而且每次研发都会将责任推到测试,每次又被我挡回去。周而复始。。就算有高层的协助,整个研发人员的素质也跟不上。他们的概念只是停留在测试发现BUG就是给他们找麻烦的基础上。至于什么软件做的好点,市场竞争力会更强。这些似乎只是拿来说的。。尤其是待的久的那些研发。自己做不到,就将这种状态延续下去,新来的人员也跟着学。
  我们公司的产品,是不缺市场的,但是就是做不出来。每次都是因为产品延误商机。。记得刚进公司那会,研发特别喜欢干涉测试人员的思路。测试测出什么,跟研发说,各个还挺不高兴的。最后就干脆说,不要这样测,这样不对的。。更有甚者,出现错误后,策四人员还在进一步验证,他跑过来冲着测试大吼。不要拿这个测了,这个问题就这样了。。晕,这也是我跳槽中从没遇到的环境。
  我倒是想到一个问题,测试文章中有一篇如何与开发沟通的技巧什么的。。文章总是教育测试人员要细心、耐心,这样、那样,那研发人员倒是可以随便怎么样。不过我现在不这么想。先礼后兵。开始我会好好跟研发沟通。如果研发一而再再而三的这种态度,那我为什么还要这么有礼貌呢?呵呵,事实证明。我的想法没错。只要好好跟他们说,那是绝对不理的。态度强硬些还有点效果。。哈哈,这仅限于我的公司哦。别的公司一般不会的。
  至于这种诸如此类的事情。多的不得了。后来就算是领导跟我说要注意沟通的态度,我也不听了。因为实在没办法遵循。
  其实我觉得,这几年我在这个公司遇到的情况。其他公司也有的。而且不在少数。开发理由总是那么多,总是有各种的理由。总是可以有N多不改。哪怕是客户的要求也不管。小型一些的IT公司这种情况应该是很普遍的。
  当然,应该也有那些比较规范的公司。但是我想可能都是比较大型的公司。由于早期就慢慢的在约束,在规范。现在都形成了自己的一套体系和规范了。
在软件公司待着感觉每天都是周而复始的重复这些。真是有些厌倦了。。。呵呵。。所以也在慢慢决定不再做软件了。试试别的领域。这一行待久了。跟人打交道的太少。思路也越来越闭塞了。。。。。。。。只是随便聊聊,我目前的这个公司是个极品的。很多事情只能是在这里才遇到的
作者: 愚人    时间: 2009-7-2 13:17
感觉测试行业正在畸形的发展……
作者: sincor    时间: 2009-7-2 13:23
确实是极品。。。
作者: stilldeeppool    时间: 2009-7-2 18:18
行业通病了.很多程序员心里是不怎么看得起测试人员的
所以刚和他们接触时.一定要用自己的能力来证明给他们看

做到有"理"有"据".学会采用规范的测试方法.不仅仅是发现问题.更应该要学会帮程序员找到问题
对于不规范的地方要及时的向负责人提出来.对于不规范的地方要敢于说不
作者: scdxorange    时间: 2009-7-3 15:03
我们公司还好,测试人员和开发人员能够心平气和的讨论问题,而且一定要过了测试这一关,产品才可以发布出去。我觉得楼主不要对测试行业失望。顶多跳个槽吧?
作者: leeweige    时间: 2010-4-19 22:14
这样的公司能发展么?Unbelievable!
但是完全地强烈地不同意楼主的说法:“这一行待久了。跟人打交道的太少。思路也越来越闭塞了”。其实测试是一门艺术,更是一门沟通艺术,只是你没有体会到罢了!
作者: resmanm    时间: 2010-4-20 19:25
软件测试的发展需要公司的重视,否则无法抬头;
作者: liangshi    时间: 2010-4-21 12:21
好文章!学习了。
作者: 蓝染惣右介    时间: 2010-4-21 14:58
学习了
作者: honglc    时间: 2010-4-21 17:45
呵呵,这正是中国软件业发展不起来的原因。除了几个巨头外,全是小作坊。
作者: JAXON    时间: 2010-4-21 19:03
同感
作者: xingxing0205    时间: 2010-5-22 15:20
。。。。。。。。。。。。。。。。。。。。
作者: ffonline    时间: 2010-5-23 03:08
所以微软里面有PM这个职位,就是负责协调测试和开发,一个bug到底重不重要,需不需要修改,由PM决定。虽然罗嗦了点,但是很有效。
作者: havards    时间: 2010-5-24 09:55
这个是你们公司上层的问题,我们公司就不错,我做测试就比开发的工资高!
作者: bjangle.happy    时间: 2010-5-24 10:07
我们公司也是,很多时候,开发人员对你说这个你不能这样测,应该怎样怎样……更有甚者,他们看到那么多的bug说难道这些bug是必须要改的吗?优先级有那么高吗?不能往后推迟一下吗?听到这些话,我好郁闷……有时候感觉,好像测试就是一种形式,你只要发现bug记录下来就O了,bugFree上的bug几乎没有人来解决……
作者: lshtesting    时间: 2010-12-18 12:47
我们公司还好
测试和开发协调得不错,有时候还会因为发现了一个难以发现的BUG而受到开发的表扬呢。
作者: lshtesting    时间: 2010-12-18 12:47
我们公司还好
测试和开发协调得不错,有时候还会因为发现了一个难以发现的BUG而受到开发的表扬呢。
作者: caoase    时间: 2011-1-8 16:10
你的帖子真长,周六的下午看得让我想睡觉。

你上面所提到的问题,我大概能理解。找到一个合适的团队,和同事一起开心的工作,是我对我自己的要求。
但是,我想很少有人这辈子就在一个团队里工作吧,团队不解散,我也会厌倦的。
那么,当你进入了新的团队,如何能开心的工作?如何建立相互的信任,这就要看你自己的技术和为人了。
以测试技术让开发信服,以为人让开发信任,以德服众,以才服人。
假如,贵公司的QA团队里找不到那样的牛人。那么,恭喜你了,那个牛人只有你自己去当了。谁让你是测试主管了,当有一天开发从内心深处和你交流的时候,谈论到他自己的人生的时候,那么,你的问题就解决了。
作者: lctlee    时间: 2011-1-8 18:33
呵呵,楼主说的确实是大实话。
怎么说呢,别的地方我不知道,我在深圳工作,经历过外包与非外包。我就说句到家话吧:关键在于人,人数,也就是规模!在大公司做事有流程感,在小公司做事有作坊感。原因在于,大公司整个从事软件研发的人数使软件研发这个事能按流程走,每人各司其责,自然给你的感觉就正规的多;中型公司只有一个或几个研发项目组,就算每个项目组的人员能按标准规模齐备,但由于其项目组不多,无法形成项目级别以上的流程规范,也就导致其整体项目流程要么变成学人(比如现在的是个公司都过了CMMI3级,但有几个是按CMMI来实际做的?),要么就成了有本司特色的项目流程(变相的作坊流程而已);小型公司干脆连项目组内都人员配备不齐,谈流程那就是扯淡了。
但这里也不能就这么简单分类,这还得分外包和非外包,其实如果你想要有流程的,那大可选择去那些外包到大公司的项目,虽然人家大公司的正规流程啥的和你没啥大联系,但最少你是在那个环境下工作嘛。可惜,这种事我不喜欢,我从了那种自己的作坊型的。。。
还有楼上哥们说的我不同意,开发是开发,测试是测试,怎么了?我做测试还非得要你开发瞧得起我?我也没那个义务为了工作主动和开发近乎到谈论他自己人生的地步。我这人做事的原则是,你希望一起做好事情,我就和你一起做好;你开发要是扯淡我测试比你还能扯!有BUG怎么了?有我的责任有没你的了?要是老大因为这个来和我BB,我坚决我惯着这套,这年头,炒个老板又不会怀孕,别逼哥!
作者: sophie_wang    时间: 2011-1-13 13:00
刚开始转测试的时候,还壮志雄心的,想学会这个学会那个,然后10年内当个测试顾问什么的,然后衣食无忧、不愁找不到工作。。。。
哎,现在干了一阵子,觉得一切都只是梦想啊。
身边的人,5年、10年的,参加过的项目很多,经验那么丰富,最多也只是个TL,连TM的都很少。。。
真不知道以后该怎么规划。。。。
作者: 582357212    时间: 2011-1-20 15:49
回复 15# havards
是同一文凭同一工作年限么,如果是  我只能说 很好 我顶你,如果不是,那你拿两年工作经验和一年的工作经验的开发比有啥意思。
作者: 582357212    时间: 2011-1-20 15:54
呵呵  万法归宗,每个人经历不同,价值观,看事情的角度也不同,什么事情都有好的一面也有不好的一面,经历多总不是个坏事 我觉得
作者: 582357212    时间: 2011-1-20 15:56
任何问题寻找解决方法我觉得才是根本,而解决方法就是工作能力。
作者: music178    时间: 2011-1-28 15:46
楼主说的很对啊,学习到了
作者: tengmy    时间: 2011-1-28 17:20
楼主的切身体会让我不禁想起了从前的日子。
在第一份工作,在松下做手机测试的日子,因为bug的修复与否和开发人员战火纷飞的日子;在ibm和牛哄哄的开发人员PK的日子。现在想起来,都是一份苦涩和更多的感叹吧!
其实很多时候,是自己不够强,对于客户的需求理解的不够深刻,所以说的话不够有权威。而开发人员不知道被谁惯出来的咋咋呼呼的毛病到时随处可见。
我觉得在楼主这样的环境里面,无论在处于何种职位,都是难免郁闷的。因为开发人员的不配合,因为公司的不够重视。这在中国是一个不可避免的事实。
对于自己来说,如果还想继续在这条路上走下去,就记住四个字吧!坚持!沉淀!坚持不断的学习,坚持不断的研究,坚持不断的自我挑战,坚持和开发人员的战火纷飞。然后自己总结。每一次经验都能自我反省,沉淀出有用的东西来。
有些时候,环境我们无法改变,那就让自己多学可以学到的东西。在某个适当的时候,找到一个可以接受的平台,潇洒的离开。
作者: 963940800    时间: 2011-4-21 14:55
社会真的那么复杂么?每天都是勾心斗角的么?。。。。。。唉,人活这真累。。。。
作者: lenfeiyang    时间: 2011-4-21 15:19
小公司,真的很难展开正归的测试,我们公司这方面很好,都是开发人员怕我们测试,也有一些新来的开发牛逼哄哄的,你提个BUG他还生气,开发的项目经理个个都通情达理,但那些新来的一般一段时间后都是会尊重着测试人员了
作者: 航空    时间: 2011-4-25 10:32
回复 20# lctlee


    说的不错,我也在深圳搞测试,你在哪啊?
作者: neusoft_shen    时间: 2011-4-28 16:27
看完楼主的话 作为测试 我心寒
作者: xian125521    时间: 2011-5-3 17:15
不知道作为开发的他们会不会有这么多的感慨。
作者: 804845430    时间: 2011-5-3 17:24
呵呵 ,不错,我到目前感觉测试和开发人员的沟通是个不错的研究点,值得好好研究的
作者: soarsky629    时间: 2011-5-4 17:39
测试的确始终没有被重视…………久而久之,测试会变成开发人员的奴隶!
    好想改变这个现状,但是无奈,只有提高自己了,别人才会服you!
作者: selftest    时间: 2011-5-11 17:05
我很佩服你在这种环境下没有选择逃避而是坚持了这么长时间,我相信这对你之后的人生也是很有帮助的,“以测试技术让开发信服,以为人让开发信任,以德服众,以才服人。”说这话的兄弟我更佩服,学习了
作者: rtxf    时间: 2011-5-12 09:14
还好我没有遇到那种情况,我们公司这方面还是蛮好的,开发和测试都挺协助的,开发还怕测试的,就怕我们找到bug找他们
作者: wangxin1618    时间: 2011-5-12 21:04
自己模块的BUG在测试阶段被发现 开发的应该庆幸,等到产品交付了 再出一些重大问题 那就完蛋了!




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