[如需转载,请在转载时注明出处,并保证本文的完整性]
你要为自己每一次的懦弱而忏悔:曾经不愿承认自己出生于农村,曾经不敢面对自己是一名外包员工,曾经一次次的不甘心自己只是一名测试工程师。
不做失败者
微软、IBM、Oracle、华为等等,这些公司选拔的测试工程师应该都是出类拔萃的人才。可惜不是你,说起你的大学,就想起郭敬明的《一梦三四年》。你开始想做测试是因为数次面试程序员被拒,但是却看见了“月薪8000不是梦”的广告。比起进入外企、国企、名企的同学,比起考上公务员的同学,比起做软件开发的同学,你在心里问自己“我是个失败者吗?”。我只能说你还没有成功,但是你已经开始挑战失败。
一名测试工程师
你有了正式的Title:“测试工程师”,我只能改编《双城记》里语句来形容“这是一个最美好的职业,这是一个最糟糕的职业。”
你的脑子里充斥了各种词汇“白盒测试、自动化测试、测试工具”,可是开始测试任务以后才发现自己用的最多的测试工具就是缺陷管理工具,用到最多的测试技术就是点、点、点,测试组里最受重视的是懂业务的老员工,项目组里最低三下四的是测试。被开发说“这不是BUG,你操作有误,就是这样设计的”,被需求人员鄙视“怎么最基本的业务也不知道?”,测试经理找你谈话时委婉的说“在发现BUG的数量上你还需要努力”,马上就要发版本了,项目经理召集测试组开会“今天开始不要再关注界面的、易用性的、与核心业务无关紧要的BUG”…
受了最多的委屈,拿着项目组里最低的工资,你都承受下来了,我佩服你。
今天你再回头看看,肯定会微笑的领会当时的收获。高强度的手工测试培养了测试的Sense,BUG数量的压力激发了逆向发散的潜力,研究复杂的业务锻炼了测试思维。经过与开发、与需求的交锋,逐渐从逆来顺受转变为对抗。逐渐学着站在项目的角度思考测试,为什么要提前测试?为什么要首先关注核心业务?有些BUG为什么不应该提?
最重要的是你加入了一个团队。当发现一个牛X的BUG,只有在给大家分享时才觉得无限光荣;当抱怨需求变更时,那么一帮人一起泄愤才最解气;当测试一个模块时,几个人一起抢BUG那才刺激。
跳出去
逐渐适应了环境,你就开始了几个阶段的胡思乱想:“我不要做手工测试了,我要做自动化测试”;“我不要做测试了,我要转开发”;“我不要做测试了,我要转管理”;“我不要在这个公司了,我要换更好的公司”。
当你开始在组里照葫芦画瓢的录起来自动化测试脚本,你问自己“这就是自动化?”。你觉得用录制工具没有技术含量,就开始用开源工具、开始自己写测试框架,一遍遍调试,面对需求的变更整晚加班来特性化自动测试程序,你对自己说“写程序真繁琐”。你受够了技术工作,开始主动承担些带新人、任务分配、计划文档编写等工作,你和别人抱怨说“我怎么成了个打杂的了?”
那么回过头来发现,认认真真投入项目中,仔细研究需求、认真的设计用例、严谨的来执行测试、适度的实现自动化、积极的分担别人的任务,只有这样才感觉最充实。当面对繁杂的需求文档,理清了思路画出了流程图;当看着自己设计密密麻麻的测试用例;当发现自己在原有框架上所作的特性化修改可以完美地运行;当看着自己负责的测试任务井井有条的进行着,自己辅导的新人积极向上的成长着;这一切的喜悦的感觉,都是全身心投入你目前的工作所换来的。
学无先后
你已经不再是二十岁出头,开始怀疑自己还能学会新的技术吗?不是说过了25岁就开始记忆衰退了吗?那你知不知道,随着年龄增长,阅历的丰富,理解和领悟能力会越来越强,虽然你比新人学得慢,但是在项目经验方面的优势却能帮助你有更深入的理解。知识是相通的,就比如当你研究明白了一门编程语言,那么再学习新的就会很快。测试也一样,测试工具、测试思想、测试流程都有很多种,不可能样样都会,深度的扩展是广度的前提。
有人说程序员几天不学习新技术就跟不上时代了,那么测试工程师在工作中用到的技术却是稳定的。不断地重复类似的项目,不断地重复测试、修改测试脚本,你被惰性包围了吗?开始觉得不需要学习了吗?即使学习了新的技术和思想在项目中用不上又有什么用?
学了一定要用,大多数时候领导为了规避风险,不会太支持你把新的技术或思想引入测试项目中。原来是传统迭代流程,你说要学习敏捷;原来是QTP,你说要换Selenium;原来是ST测试,你说要开展ET测试。你必须要私底下多做研究、多做实践、有较成熟的方案和技术。那么在真正有机会实施的时候,你才能够一展拳脚。实践----学习----实践,循环中不断进步。
学习分享,在公司里,你开始学习了一门新技术,很新鲜,很有成就感,心里窃喜“看他们都不会”。这样下去有一天你会失落的发现,同事们开始对你的新技术不感兴趣,因为他们不理解,你提倡的技术思想因为无人认同而无法执行下去。与同行交流,你想炫耀一下刚学习来的“探索性测试”思想,她给你来一句“和自由测试有啥区别?我早就知道这个”,你想推广一下敏捷,她给你说“敏捷就是没有文档吗?好啊,终于不用写文档了。”你哭笑不得。
这时才会发现,个人的发展和进步,需要团队的共同进步,需要行业的共同发展。这一切都来源每一个你这样的测试工程师的进步与分享。