本帖最后由 kanelai 于 2017-8-24 21:33 编辑
新兵入伍
上班第一天,首先是到外包公司去报到,然后B见到我很高心(我是生蛋的母鸡),笑眯眯地嘘寒问暖。完事了就带我去客户那见客户的大头C总了。第一天上班,我的行李还在邮局邮寄的路上,于是穿了件超级休闲的衬衫去。。。想想自己也够拼的,8月31日结束实习且退掉巴黎的房子,9月1号早上就坐火车去南法,9月3号上班。。。发现自己每次要离开一个地方都会有点狼狈,或者说,自己故意让这个停留的时间减小,潜意识怕自己因为留恋而伤感?
见了C大,我说我来得比较急,西装衬衫都在邮寄中。。。C大貌似开玩笑地说了句我们这第一天规定是要西装革履的,我真当开玩笑就没在意,后来和C大工作一段时间后发现人家当初没开玩笑,就是有这个抠门的潜规则,他自己的潜规则吧。。。
走到自己办工作面前,看到电脑上贴了我的名字,还有键盘上放着一个信封,装有一些我账号信息,欢迎信等等。办公室是个四人间,另外三名同事,一个意大利人A姐,一个法国人MG姐,还有另外一个法国人O哥(度假中)。第一天上班貌似就在各种设置账户中,当然还有新人培训(总共要持续3天),让每一个同事负责培训我一小块知识。这样很快就和所有目前或将来要合作的同事都有了些交际。上班第二天,有个培训,我一直在等同事来找我,结果等了快半小时人家都没来,就问了坐我旁边的MG姐,MG姐立马教了我正式上班以来的第一课:永远不要等别人,你得主动去争取,不能被动。 负责培训我的同事貌似心思都在养狗上,明显我和工作都没有狗重要。后来发现这简单一句话,其实真的好有用,因为在之后几年工作里发现好多人就是一支牙膏,你不push就不动,更别说有些牙膏里面是空气,你push了也只会出一点点。。。由于在巴黎搬家的慌乱中还没缓过神来,有一天下午培训我简直快睡着了。。。培训我的同事人也特别好,看到我有点困了就说要不我们去喝杯咖啡吧。。。我觉得要是我在国内工作这么打瞌睡估计要被贴各种偷懒标签了,这也让我感受到了欧洲人的容忍,大概人家觉得累了打瞌睡也是正常的,这是大自然的规律嘛。。。尽管我跟她喝完咖啡因为聊天聊太久脑子烧掉不少能量反而更累了。。。于是这样又过了一天。。。下班时间我也算是跟同事打探了一下,说一般早9晚6,中午休息2小时。后来才发现我打探的这个同事(MG姐)是全公司的劳模,干活最认真的那个了吧,她每天都是8点到晚上7点走的。。。工作一周多以后,法国人O哥回来了。O哥是搞笑型法国人,有了他办公室的气氛活跃了很多。O哥对中国人也很感兴趣,各种问我见闻。总的来说,我对这个办公室组合很满意。
工作一周多,和周围同事交流了,慢慢了解自己的组以及项目的情况。我被分到的组所做项目算是公司当时最重要的项目,北美第一个大客户,也是北美载客量最大的航司。所以组里经费也很多,而且也号称是在整个QA部门里面挑的精英组建的。获知这点,突然觉得自己好荣幸,因为任务越重越难成长越快。而且我那时算是半个白板,周围的人都是我老师,有个好老师也是蛮重要的。
我刚开始主要的工作是写和跑手动测试的脚本。大家可能会好奇用什么语言写的,我可以告诉大家是用英语这个语言写的。。。what,有Java吗?没有。有VB吗?没有。没错,就是纯英语,写执行步骤。然后另外一人在跑测试阶段就照着测试步骤描述来一步一步执行,然后判定过还是没有过。想想我实习的时候,接触到的都是当时测试行业最先进的技术,比如自动化测试脚本啦,持续集成啦,等等。我在新公司看了圈,貌似都没有。。。心里落差还是蛮大的,特别是对一个心高气傲的年轻毕业生,刚挽起手袖准备大干一场却发现可以把袖子放下了。。。那时候明白,实习和正式工作的区别,实习你可以天马行空,干啥都行,因为不涉及公司的正常业务(法律禁止实习生的工作替代正式员工的工作,以免公司低价聘用劳动力)。正式工作是上面的大脑决定了下面的人怎么干,下面的人信息要想往上传导还是有点点延迟,特别是对新人来说。
不过还好在法国生活了两年,自己的耐心也慢慢练下来了,想着无论怎样,都先好好干下去再说。更何况自己还在试用期里面,之前还听说有人试用期被开掉的。。。抱着这个想法决定好好跟着同事把活做好。
我的第一个任务就是跑测试,照着别人之前写好的测试脚本(英语阅读),一步一步的执行,然后记录结果。做这个的目的是了解一下别人是怎样写测试脚本(英语作文)的,然后为以后自己起草脚本(作文)打下基础。
测试跑差不多了,开始写测试脚本。基本上就是我先去找到我要测试的那一个小功能的相关文档,技术上的,功能上的,都最好看一遍。然后用excel表格列一个测试矩阵,横向列举出要测试的点,纵向是把测试的点按照合理的排列组合生成不同的测试。这个活其实很考耐心和表达能力。要用简单的矩阵来表达你要涵盖的测试点,逻辑上还要按照先简单后复杂来进行。基本思路是,每一个测试要有且只有一个测试目的,而不是杂糅了好多个不同的目的。 原因是,跑测试的人一般会遇到测试失败的情况,如果一个测试只有一个目的,那么肯定是这个目的没达到才失败的。失败的原因很明显。如果有多个目的,那么失败的原因是多样的,有可能是一个目的没达到,或者是多个。并且,如果bug被修好之后重跑,含有多个测试点的测试有可能目的A这回达标了,然而目的B上回达标这回不达标,于是测试又得标记为失败。。。这样搞下去,这个测试会很难跑过。当然,这种多测试目的的测试不是说绝对不能有,在一个稍微复杂的功能测试里面,是应该有一到两个这样的复杂测试。不过这些测试一般会在前面的简单测试都跑过的基础上再跑,因为这时候产品开发得比较成熟了,跑这些复杂测试也比较有意义,可以发现一些复杂情况下才会有的bug。
测试矩阵写好以后,是要求发给另外一个同事进行review校对的,主要是要保证矩阵的质量。我的第一个矩阵是让劳模MG姐给我做review的,大家应该能猜到结果了。。。MG姐很认真的先读了我读过的文档,然后就我的矩阵,找出了很多很多很多修正建议。比如,有哪些点漏测了?有哪些点不合理?有哪句话看不懂?有哪些拼写错误?(还记得MG姐姐当面和我说,嫩知道看你矩阵的人很可能是美国佬哦,人家那是母语哦)有哪些测试没必要?有哪些东西文档没说清楚,得找人问问?找人问unclear points 也绝对是个技术活。首先要表达清楚,主要都是靠邮件。而写邮件的好处是可以把领导放在CC里面,而且可以留个底,把疑问都放在台面上,大家都同意了就算以后出问题了,责任也是有人承担。当上升到负责任的层面了,回答问题的人也会更加认真。
测试矩阵在来来回回修修补补后,要是通过了review了,就可以开始写测试了。测试矩阵写得好的话,测试就很好写了,因为大部分疑问都解决过。当然,测试步骤的描述也是更加考耐心。记得当时MG姐老说:你得把你的测试步骤写得让一个门外汉都能看懂,只要照着来操作就能达到测试目的。 要达到这一点,其实还是不简单的。正所谓 A picture worth a thousand words。换位思考之,如果要用英语来描述一个picture,估计也得搞个上千字吧。。。所以如何用最精炼语言来描述各种图形界面的操作,真是蛮考耐心和技巧的。那时我明白了当初面试的是PJ大大让我在白纸上把自己的思路有条理写出的原因了。。。如何清晰表述是做一个QA的基本要求啊 。
写测试矩阵和测试步骤这两个工作贯穿了我这第一份工的大部分时间。或许很多人会觉得这些东西简单枯燥重复(类似的测试经常可以复制粘贴的。。。)。然而我觉得这是对我QA生涯打下基本功的一个重要练习。虽然这个公司不是世界最顶尖的IT公司,但是我感觉我当时所在的组在QA工作上的很多流程和规范算是领先水平的。
2017-8-23 20:34:51