微软外包经历的第二篇,首先很感激很多朋友读了我的文章后给了我非常积极正面的反馈,我也很高兴自己的文章能给初次踏入或者准备踏入这个行当的朋友一些帮助;在“提手”开打写第二篇的时候,我对之前的第一篇有了些反思:因为之前写的非常的随性,基本上属于想到哪写到哪,后面的几篇文章我想先列出个提纲来,一来可以理清自己的思路,二来可以为自己的填坑行动寻找到目标;)
关于测试感悟的系列:
说说对微软外包的经历,献给那些已经入或将要入这个行当的朋友们(1)--Good start, half done
说说对微软外包的经历,献给那些已经入或将要入这个行当的朋友们(2)--No pains, No gains
说说对微软外包的经历,献给那些已经入或将要入这个行当的朋友们(3)--New start?
关于测试技术的系列:
测试驱动开发实战(1)
谈谈如何搭建一个UI测试框架(2)
单元测试--你也可以做到(3)
也谈性能测试(4)
测试实用工具汇总(5)
接上回,不论什么行业,一个人一旦踏入了就只有一个选择,要么不停的让自己成长去适应这个行业,要么转身离开这个行业;所以这次谈谈楼主在这个行业里经历的一些让自己成长的“痛苦事情”。
作为一个老老实实勤勤恳恳又努力的测试人员,平时干的最多的两件事情:一个是跑测试,另一个则是找BUG啦:
跑测试很好理解,一个产品交到你手上,你既可以一边对着设计文档,一边测试;也可以什么都不管,先乱点一通先;总之一句话,怎么容易出问题就怎么折腾这个软件。那找BUG呢?
楼主我在这个行当里遇到的第一件麻烦事就是如何找BUG了:明显的BUG人家早就早早的给找了出来,剩下的一堆BUG要么是不容易复现的,要么就是所谓的corner scenario;最后披荆斩棘般辛辛苦苦发现了BUG,找到了repro steps,结果一放DEV那边,人家随便给你解成by design, not repro, won't fix或者是duplicated。 这对谁来说都是件让自己心情不爽,但是却又常常发生的事;
步入第一个项目组才3天时间,楼主就面临了人生第一次的TP,期间报了一个BUG;结果第二天时间就被美国的DEV解成了duplicated;我仔仔细细的拿着这个BUG和我报的BUG比了半天,一点头绪都没有--为什么呀?明明两个风马牛不相及的东西,也能解成duplicated。正当我百思不得其解的时候,我的lead走过来看了看这两个BUG,解释了起来:“你这个BUG只是他的BUG的表象,他的BUG才是本因”;“噢,原来是这样”。如果说跑测试需要的仅仅是清晰的思维和对产品的熟悉的话;那么找BUG这个环节还需要测试人员扎实的基本功和技术水平了--如何快速分析出现的问题以及发现问题的本源。
第一个TP给我的映像就好像是一头老水牛拉着几百公斤的货物走在泥泞的路上,几乎是懵懵懂懂的,迈着缓慢的步伐就这么闯了过去;期间多亏了我们的lead筒子非常耐心和不厌其烦的解释,让我等后进之辈还能勉强赶上整个组的进度,再次向他表示深刻的感谢!!
之后的几个月里我过了一段风平浪静的生活,但在这期间楼主却因为要熟悉产品的各方面结果弄的比跑TP的时候还要累:每天早8:00晚8:00的日子也过了不少;有的时候懒的吃晚餐,就将就着拿微软为一些加班的同事提供的面包,方便面充饥;在这段平淡的日子里,我对产品的各个feature 渐渐熟悉,也对自己找的BUG越来越自信了,其中也不乏一些高质量的BUG,获得了诸如"nice catch","great work"之类的评语;而项目组的本身也发生了几次人事变动,做微软外包的稍微早一点的朋友应该知道,07年那会很多组还不是像现在已经的single vendor而是几家公司的人混在一起,所以项目组本身的机构也非常的不稳定;那个时候,我最初带我的那位lead已经去了其他的项目组里;而整个组里只有我对产品最熟悉,就在这样的背景下,发生了一件不大不小,但是对我的意义对很重要的事。
这天晚上,我惯例般的耗在办公桌前,想着明天要干的事情,突然outlook显示出我收到了一封新邮件:打开一看,原来是PM抄送给全组的一封信,里面的内容是一位美国客户的抱怨。这位客户是美国一所高校IT部门的负责人,我们的产品当时部署在了他们将近上万台的机器上。现在他们想装另一个产品,但是这个产品和我们产品的某个feature发生了冲突,于是问题来了-- 如何能批量的通过某个方法来关闭我们产品的这个feature呢?邮件被设置成了high important,而我们可以依靠的DEV team的两位老兄此刻也悠闲的休假去了。。。突然我觉得好像这个问题只能靠我来解决了;跑去洗手间狠狠地用冷水冲了下脸,然后在太阳穴处压了两下;我跑到电脑前,尽量装出镇定的语气回了邮件,询问对方时候有批量部署的软件来做软件部署;过了5分钟,对方回信了,“是的,我们有;我们现在缺少的是一个可以调用的API或者方法来操作这个软件来关闭这个feature”;目标明确了,对方缺少的是一个方法,那我该怎么办呢?我想到产品的手册里面有自定义产品这一节,于是赶紧把产品手册翻了出来,找到了这一节;并依照这些说明写了一个实现这个方法的脚本,打包,上传,看了看时间,只过了半个小时,但是身上却不可思议的渗出了汗水。。。这个脚本有没有被他们用到我不知道,不过那天晚上我在他们的感谢邮件下心安理得的睡了个好觉^_^
一句话来形容这个阶段的我,就是“no pains, no gains”~一段时间里,一直都没有睡过安稳觉的我,深深地体会到了这句话的含义。