走路要向前看,但也不要忘了脚下的路.

新加入一个团体,如何能尽快的展开测试工作?

上一篇 / 下一篇  2009-03-21 12:13:30 / 个人分类:工作心态

 
新加入一个团体,如何能尽快的展开测试工作
来自51testing测试论坛poission的发表
组里刚来了新人,刚好大家也帮忙看下,有没有带新人的时候有没有什么要改进的
1. 人际关系
这个很重要,我把这项列在了新人的今年计划上面,不光是QA内部,还有和DEV,公司QA,任何和工作相关的人的关系. QA和DEV的关系很微妙, 所以我觉得新人如果给自己定位不对的话,很容易走歪.

2. 态度
新来的MM每次问我问题都和我说谢谢,搞的我都不好意思了,但是这是对你起码的尊重. 听另外一个同事说, 他带的那个新人因为有靠山, 回答她问题变得理所当然的事情, 连谢谢都不说, 还指示他,你应该教我这个,教我那个, 那味道就不好了(同事和他的新人都是外国人..), 所以那个新人来公司3,4个月了, 都没给她什么任务.

3. 主动
我刚进公司那会, leader直接告诉我, application怎么下, test case在哪儿 (那时还没Use case呢), 然后自己跑, 碰到问题再问. 然后我就每天把看的结果告诉他, 把问题列给他, 然后他再给我答复. 差不多2个星期就上手了吧..不过也发现那个application上面很多bug,搞的我们leader都不好意思了呢~
现在我带新人, 基本就是把简单的流程演示下, 把相关的文档和test case发给他们, 照着文档跑. 然后有问题再问我. 因为我不可能把所有的东西一股脑的都传给新人, 更何况,每个人的测试思路都是不一样的. 有问题, 说明你在学习,思考, 然后才是有效的理解. 而且,我相信, 好的leader是喜欢会challenge自己的下属的. 所以, 作为新人, 要主动出击, 多问问题~

4. 及时和Leader沟通
这个方面, 就不光是技术方面的了, 还包括对进公司的感受, 自己的职业发展方向的想法了, 要让leader觉得, 自己可以帮助到你, 不过说到底还是一个沟通技巧了.


还有一个方面就是技术上的准备, use case/requirement/test case是很重要的一块, 也是必须要看的. 剩下的一些process的东西, 我倒是觉得没必要一开始就弄的很清楚. 慢慢来, 一切都会清晰起来的, 相反, 项目上要想尽快上手, 就必须把测试相关的抓好, 并且要让leader, 你ready了.

事情是做出来的, bug是找出来的, 光说不练是没用的
 
来自51testing测试论坛zhuzx的发表
作为一名测试新人加入团队,大多数情况下,项目组成员都是一种热情欢迎的态度,并且主动提供力所能及的支持和帮助,如何快速熟悉项目业务和测试环境,尽快投入到实际工作中去,我谈谈个人的经验和一些看法,供同行参考:

1、寻找新公司的团队元老:

  一般来说,一个新人进入新公司,都要指定一个师傅带一段时间,这也就是我们说的测试前辈。很多时候,测试前辈都是经验非常丰富的测试高人,如何您和他相处融洽,关系不错,凭他个人丰富的业务经验,给您指点迷津,也许会比你自己摸索10倍的时间效果还好。很多的测试新手,刚进入新公司时,自高自大,眼高收低,测试前辈都不愿意交,结果到了试用期转正答辩的时候,一问三不知,被迫离开公司,被炒鱿鱼。这样的例子我看到的不下于10例,很可惜丢失了很多工作机会。

2、虚心的学习态度:

刚到一家新公司,保持谦虚的学习态度非常必要。记得我刚毕业那年,公司招聘了一个测试主管,他有4到5年的工作经验,阅历算是不简单,也是我们心目中的牛人吧。但是那个人,除了听总监的话以外,对于我们部门的其它人来说,他简直是自高自大,目中无人,根本不把部门里的其他人放到眼里,觉得部门的人都不如他。他作为一个空降兵,老员工和新员工,对他都很冷漠,碰到什么问题,需要小组成员帮忙的时候,大家都不愿意帮助他,互相推诿,并且经理也找他谈了几次话,效果不明显,结果他呆了不到2个月,估计是自己觉得很不开心,被迫离开了公司。其实,保持低姿态,谦虚的学习态度,必不可少。

3、阅读项目相关的文档:

  一般来说,新人一到公司,就会安排到项目中去。作为测试新手,快速阅读相关的“需求文档”、“详细设计文档”和“用户手册”特别关键。我们能够通过需求规格说明书等文档,快速熟悉系统相关的知识,获取编写测试文档的相关信息。如果项目已经编好了用户手册,您完全可以根据文档的步骤,一步一步傻瓜式的熟悉每项功能。只有掌握的这些文档的精髓,测试才会变得异常轻松呀。

4、快速熟悉项目相关业务知识:

刚到新公司的测试人员,如果你是跳槽到以前做过的相近行业,有丰富的经验了,那么您熟悉业务没什么大的问题。如果您换的新公司是您以前都没有接触到的行业,那你一定得努力一点,买些相关的业务知识看看非常必要。我深有体会,以前从一家“通讯公司”跳槽到做“银行系统”的公司,业务完全两样,很多业务知识都是从零开始。不过有一定的工作经验,学习起来也挺快,关键取决于个人是酷爱学习和坚强的学习毅力。

5、尽快介入了解被测试系统:

   刚跨入一家新公司,如果被测试系统已经开发的差不多了,部分功能已经OK了。你可以部署到测试环境下,尝试从直观测试的角度去尽快了解系统,尽快结合文档熟悉起来。很多的时候,通过页面操作实际的系统比看文档效果好的多,并且印象更深刻,熟悉系统更快。新加入公司的朋友不防试一试。

6、了解公司类似的相关产品:

    大多数的公司,都不可能在每个行业都非常强,基本上都是在某一个较小的领域很强势,公司主要就是研发强势相关业务的产品。所以说,相关的产品一般来说是很多的,如果要你测试的系统没有开发完毕,如果时间和条件允许,不妨先了解一下公司类似的产品,以便尽快熟悉起来。大多数情况下,公司很多的产品都是相通的,大部分的产品是在不同的客户要求下,修改了部分功能和界面而已。个人认为:了解类似的产品,也是测试新手快速熟悉产品的一条捷径。

7、尽量多参加项目的各种会议:

    每个项目,特别是在项目的启动阶段,大会小会不断,很多时候项目组成员抱怨居多,都认为很浪费时间,耽误开发进度。如果作为测试新手的您这个时候加入,那太好了,多参加这样的讨论会。大部分时间都是在讨论项目的重点和关键,如果大家意见不一致,必然要对不一致的东西展开细节讨论,您肯定是收益匪浅。特别是对业务方面的讨论,您参加几次讨论,比您看10篇需求还强,并且理解也很透彻。如果您对需求有所了解,但是部分功能模块还有问题,就可以在讨论会上随时提出来,大家一起讨论,共同解决。如果有这样的机会,切勿放弃哟。

8、阅读类似项目已有的测试用例:

   如果项目已经启动并进入了测试阶段,如果你在这个时候介入,通常情况下负责人都会给你提供整个项目或部分需要你测试的部分模块的测试用例。这些测试用例也是您快速上手测试的重要参考资料。如果还没有编写测试用例,你就介入了,那你就得重头开始,您可以阅读项目类似的测试用例,并结合以前项目的测试经验,根据公司相关的测试用例模板开始编写测试用例。如果在编写测试用例中碰到您不了解和很难处理的问题,您可以记入测试需求疑问表格,等部门开会时,提出来大家讨论。最好不要碰到一个问题就去问,经常打乱人家的思路,弄得别人嫌烦,那就不值了。

9、查看缺陷数据库中旧有的缺陷:

   一般的测试缺陷跟踪系统,都是按模块来分类软件缺陷的。如果老大给你分配了测试任务,你就可以有目的的去熟悉即将测试的模块缺陷。登录系统后,对缺陷进行筛选,尝试按测试前辈的Bug描述步骤进行操作,看看是否能够重新缺陷?这种方法能够借鉴测试同行的经验,尽快发现问题,避免测试的盲目性。一来可以拓宽您的视野,避免递交类似问题的Bug或是重复的Bug,二来还可以为您快速熟悉被测试系统添砖加瓦。

10、必须明白自己领导是谁:

   一般的员工进入公司,公司和部门领导很多,搞不清楚谁管我,碰到问题问谁?谁可以帮忙解决问题?如果真是这样那就麻烦了。部门领导臃肿的情况实在是太多了,有的公司,既有2测试经理,又有几个测试主管,还有多个项目经理和研发总监,不知道工作向谁回报,对哪个领导负责。弄得每个领导都回报,很累呀!!我的做法是:测试项目中负责领导只有一个那就是测试主管,测试主管负责安排和分配每个测试人员的工作和任务,我直接Review测试主管。如果项目中碰到有什么解决不了的问题,组内成员可以直接找我,同时我也定期加入项目参加部分测试,了解测试项目的一些进展情况,必要时还要找一些人谈心。这样,工作汇报比较简单明了,很轻松。

11、熟悉与测试相关的管理软件的使用:

  我说的这个测试相关的软件包括缺测试需求管理软件(如TestDirector或QC)、陷跟踪管理软件(如:TestTrack Pro、TestDirector等等)、版本配置管理工具软件(CVS、VSS,还是SVN等等),具体熟悉到什么程度,那就要看您的职位了。如果您是一般的工程师,那你就只了解一般的使用就够了,如果您是测试经理,您不仅要了解一般的使用,还要更深层次的了解软件的权限和项目的配置,因为您要作为该软件的Admin,碰到问题大部分都由您搞定呀,高工资不是那么好拿的呀,哈哈!!!如果作为新入职的您,连这些都不会,那你就得加把油了,不然到了测试启动阶段,你才开始熟悉管理软件,那么你觉的能够快速展开测试吗?

12、注意沟通技巧,把握请教良机:

  为了尽快熟悉项目,展开测试工作,沟通技巧必不可少。您作为新入职的测试人员,尽量了解每个开发人员开发的模块和每个开发人员的性格特点,寻找一些共同语言,拉近与开发人员的距离,让他们对您产生好感。只有这样,当您碰到问题的时候,他们才会鼎立的帮助您。如果您与开发人员关系不好,看了就觉的很讨厌,那他们肯定不会帮助您的,更不原意和您配合,当您提错Bug的时候,他们就会抓住这些Bug不放,有时候还要说您什么都不懂,这样你就很郁闷,肯定呆不长久的,只有走人的份了,呵呵。特别是开发人员很窝火的时候,您更要多一些理解和宽容,切勿火上浇油,您可以给他一些表扬,给他一些鼓励。他一听准开心死了,总觉得还是您们最了解我,把您当成自己人。这个时候,你再问开发人员问题,他也许态度就不一样了,他准会仔细的给你讲解,并且以后的什么事情,他也会百厌齐烦地帮助您的,因为他觉您最了解他们,无意识的把您当成了好朋友和哥们。还有的时候,开发人员有空过来测试部门逛逛,准备和您交流时,一定要把握机会,和开发人员开开玩笑和一些必要赞赏,也能够调节和开发人员的关系。总之,这一点做起来真的很难,如果做的好,那效果确实就不一样了。
来自51testing测试论坛goal1860的发表
刚进一个项目,会有两种情况,一种是项目刚启动,那只要把人头搞搞熟,流程弄弄清楚,跟着大伙一块做就完了。另一种情况是半途加入,会感到一定的压力。压力的来源有:
1。担心无法跟上进度。因为对客户业务,应用程序,特殊工具,日常流程不熟悉,千头万绪不知道从哪里开始
2。担心能力无法适应。有些测试项目需要背景知识,有些需要白盒分析技能,或者自动化脚本的能力。自己可能以前未接触过
3。担心无法适应团队。周围都是陌生人,自己是否会被很快接受
我刚进一个项目会先搞清楚:
1。自己要直接汇报的人。关系汇报和工作汇报有时会分开,如关系汇报给项目经理而工作汇报给测试组长。
2。要汇报给自己的人(当你有一定级别)
3。找到一个可以直接给你帮助的人,最好由领导指派,这样责任更明确
4。项目里怎么分组,你处于哪个组,该组的职责是什么,你会跟谁合作,开发组有没有单一联系接口
5。项目里提供一些公共服务的人是谁,跟谁申请测试机,跟谁要软件,跟谁要刻录盘,跟谁要文档模板等
6。开发流程是什么,瀑布还是敏捷
7。SQA是谁,他(们)能提供什么以及要什么
8。你的可用资源有哪些,如测试机,账号,可用的软件库,哪些是分享的,哪些是你自己专用的
9。使用哪些一般的工具,如cvs,svn,sharepoint,wiki,share folder,bug tracking system
10。项目的测试对象是什么,大体怎么测,手工还是自动化,虚拟机还是实体机,测试平台是windows 还是unix,英文还是多语言,测功能还是别的,黑盒还是白盒
11。现在处于什么项目阶段,当前的首要任务是什么,期限是什么时候
12。什么时候交工作报告,哪些例会要参加,要做什么准备
13。你有可能会最先被安排什么具体工作,写用例还是跑测试,还是搭建自动化
14。有什么特别的规定,什么事情不可以做。我们遇见过因擅自搭建dhcp/dns服务器造成的网络瘫痪
应该从什么文档开始学习
然后会:
1。下载或检出项目文档
2。安装必要的软件,包括项目要求的和自己觉得会有帮助的合法软件。有些软件如果没有用过大体上学习以下用法
3。学习文档,学习深度因时间要求而异。实际项目中很少会有很多时间让你学习,就只能过一下整个系统的概况,知道有哪些组件以及它们的大体功能
4。安装要测试的系统,并初步使用,获得一定感性认识。测试环境要尽可能地和他人一致,以便重现和解决安装中的问题。我们经常有这种体会就是系统经常“欺生”,第一次安装很容易出问题,但这种经历能够帮助了解系统和发现不为人注意的缺陷。
5。根据用户说明过一下最主要的功能场景
6。找到存在的测试用例,跑一下正面的测试用例,就可以加深对功能的认识
7。访问缺陷列表,看看是否能理解或重现缺陷,了解主要的缺陷来源,不理解的询问提交者,太深的就搁置不理
8。如有可能检出代码作白盒分析
9。熟悉或搭建自动化测试环境,学习相关工具和脚本的使用
10。熟悉项目内对缺陷报告和测试报告的格式,自己留个模板

看上去很长,其实是按一定脉络下来的。简单概括就是:理顺人脉,尽早上手,摆正位置,勤勉工作

TAG:

 

评分:0

我来说两句

Open Toolbar