如何当好普通QA

文摘   游戏   2024-04-12 16:36   浙江  

许多人熟悉这句话:人生有三个阶段,认识到父母是普通人,自己是普通人,孩子也是普通人。初听时年轻热血,仿佛大道至简;随着成长,面对现实,理想与现实之间的差距渐显。成为合格的普通QA至关重要,无论是新人还是老将,大多数人都是一线勇士。


01 前言

相信不少人看过这样一个说法:人生有三个阶段,认识到父母是普通人,自己是普通人,孩子是普通人。初闻时年轻热血,有种大道至简朴实无华感觉。从我们这代人的成长环境来看,大家可能经常在一些动漫影视剧或小说中看到满溢出屏幕的主⻆光环加持,当我们代入到主角时很容易产生热血沸腾的共鸣吧。但是伴随着升学、工作、结婚生娃,当人生阅历逐渐丰盈起来时,对这句话的体会逐渐深刻起来。通俗点说,理想很丰满,现实很⻣感,有时候付诸很多努力然而收效甚微或者往往结果达不到心理预期。学着接受平凡普通,并不代表认命,反而更能脚踏实地,努力活着也是平淡中的精彩与洒脱

近些年来在网上冲浪或多或少感受过“互联网寒冬”,“拿不到版号”,“毕业生就业难”,“跳槽找不到下家”诸如此类不容乐观的就业大环境。面对如此处境,大家选择从事游戏测试,如何在QA这个职能上稳稳扎根而不被风浪冲刷淘汰掉呢,我认为至少要成为一个合格的普通QA。读到本文的你可能是踌躇满志的新人,亦或是久经沙场的老将。很显然能统率三军,挥斥方遒的将军毕竟都是少数的,而大部分的你和我都是冲锋陷阵的一线勇士。笔者在雷火当QA八年有余,一路浮沉走来,对于如何当好一个普通QA颇有些心得体悟想和大家一起探讨分享。


02 普通QA的自我认知

普通不代表平庸

这意味着首先你能胜任负责的工作,在岗位上绝对不能浑水摸⻥。

1.

逆水行舟不进则退

人之处于世也,如逆水行舟,不进则退。是出自《增广贤文》中广为流传的一句古训。作为普通QA,完全躺平或划水亦不可取,在工作和学习上需要稍加努力,不能一味地原地踏步。

当我们在新人入职时,都可以视为一张白纸,而你便是执画笔者。在工作环境熟悉中和导师的协助下不断地探索吸收新内容,如同玩游戏时扩张地图迷雾般充满未知挑战,当开荒成功时也极具成就感。这个时期是QA积累最快的阶段,如何快速上手了解测试环境和各种平台工具的使用,熟稔项目开发节奏和测试维护全流程便是重点。

紧接着当你从一些小需求测试中成⻓到能独立负责一些较大功能模块的测试时,一般来说练习时⻓两年半是不太够的,这个阶段当务之急是在各类系统模块中摸爬滚打和沉淀努力成为团队需要的熟练手,在某块业务测试上占有一席之地,成为团队中能稳定输出的中坚力量

再往后干测试五年、六年,甚至更久,对游戏的各方面的测试工作都信手拈来,老道的经验也能支撑你有效地去指导新人工作。此时此刻可能对你直观感受上大都是重复的工作,乏味且迷茫,这个节点上你可能感觉测试干到头了?是不是到达了一个瓶颈,到底该如何去突破呢?我所在项目倩女端游是雷火所有游戏里司龄最久的,上线十二年有余,堪比游戏界的费玉清。15年入职来差不多干测试5到6年时我也时常感觉到仿徨困惑过,后来慢慢和一些更加资深的QA前辈以及其他职能的大佬交流和接触下,自己还有更多进步的空间。比如可以从产品项目的⻆度看看,如何能去更好地提高测试质量和效率,开发交付流程上是否有可以优化规范的甚至通过自动化检查提效规避人工操作的⻛险的。

总之,摆脱井中蛙的视野,跳出舒适圈方能⻅更广阔之天地。每个阶段作为普通QA都有自己可以努力和进步的方向。

2.

不当工具人

做普通QA,前提是有思想有情绪的人,并非测试执行的工具与机器。
QA在游戏开发中作为支持职能,除了编写用例快速执行找出BUG提交验证的工作外,需要更多地参与开发和上线的过程。这便是测试中心一直强调的测试左移和测试右移。测试左移需要我们在开发早期需求分析开始到交付测试前尽早地介入,了解功能逻辑的实现,评估压测⻛险,提出优化建议。测试右移则是在玩法上线后增加日志报警监控,崩溃报错收集等防御,及时跟进玩家反馈定位问题修复处理并做好bug分析和复盘。近年来面过不少应聘QA的候选人,简历看似有过不少游戏测试经验,对测试流程都算熟悉。但是就一些测试细节和经验上去问,总给人一种只会点点点黑盒测试工具人的感觉。因此我想强调的是QA也是一个很重要的职能,在合作中比其他只能多一点思考多一点经验沉淀,比起单一重复地去执行的工具人会更显灵动。

3.

掷地有声

普通QA还得会说话,敢发声

会说话是指和组内或者其他职能合作过程中沟通的技巧。本质上说就是通过有效的沟通从而达到自己的预期目标。沟通时要想清楚说明白,尽量用对方职能专业的术语,举个很简单的例子,当QA测一个坐骑时发现坐骑和⻆色挂接有问题,然后想找美术同学开单修复。初版的文案叫⻰⻢双形,文案润色后叫云⻰天⻢。如果问:道具表ID为123456的坐骑云⻰天⻢和X职业乘骑挂接交互人陷进去了。说到这不用想都知道美术同学肯定一脸懵逼,这到底是哪只坐骑呢?其实你更应该从美术的⻆度用坐骑的资源名_dragonHorse去问才能让对方直截了当地知道问题所在。沟通时多换位思考和共情,这样能让对方更好地接受或者避免互相怼起来;沟通前先熟悉起来,通过平时的相处,一些共同话题和兴趣的讨论,通过一些能拉进距离的称呼等小技巧,了解对方的性格后面对不同的人选择直接切入主题言简意赅的方式或者要更详细地说明事情的前因后果以及你的看法等等。

敢发声这意味着普通QA需要勇敢一点。面对主管的一些过于严苛的要求,项目中一些不合理的流程,我们需要勇敢地去提出一些质疑和建议。倘若有一天自己都不愿意为自己发声,一味被动地接纳,可能会让你工作多出很多不情愿去完成的内容,情绪积累压抑多了可能某个时间点就会爆发,这对自己对团队都不是好事,不在沉默中爆发就在沉默中灭亡嘛。如果大家都敢于提出一些合理有效的意⻅建议,工作要求和流程才能及时调整按大家的预期的方向走。当然发声并不是去情绪化地争论,而是通过一些站得住脚的道理或者数据去说法对方。有时候大家难免觉得QA这个职能没有话语权。但是若是你经常试着去开腔,且有专业能力支撑,其实你就拥有了一定的个人影响力,在合作中对方会对你有更深地信赖且愿意听取你的意⻅。


03 普通QA的专业能力

术业有专攻,虽然可能历尽千帆也无法成为站在顶峰的专家。但熟能生巧的我们作为普通QA最基本的测试能力和素养还是要达标。

1.

测试质量和风险把控

这个标题在我们平日工作中耳熟能详,交流中很容易脱口而出。但是实际怎么落地执行大家是否有深入思考过呢?近些年在带教或者观察到组内的新同学在交付和测试时间紧张情况下容易出一些不难想到的线上事故。往往很多时候出问题的原因是比较纯黑盒地跑功能有些边界用例的情况考虑不够或者没有评估好自己测试所需的时间加班加点也只能勉强覆盖主体流程的功能导致小错误频发。面对这种情况,线上投放的质量低其实是可预⻅的,因为从需求制作交付到完成测试整个过程就很赶,功能模块没有测试计划而手忙脚乱。面对这样的状况,如何能做到有条不紊,更显从容呢?

需求分析阶段:做好测试排期和提出压测⻛险。在早期需求文档分析开会时除了和开发达成共识弄清楚制作的预期,测试时间的评估也尤为重要。从投放的节点往前推,借鉴类似的玩法需求评估测试时间从而定下交付时间,尽量保证自己的测试时间不被压缩。前期制作的进度要多多关注,一但有进度迟滞拉上pm一起“催拉弹唱”或者先进行部分功能的单元测试。需要压测的内容早点开单,等程序交付接口后便可介入跑测。若是等⻢上投放的节⻣眼上在提出压测的需求,功能QA和测开内网服务器使用冲突,互相之间无法及时跟进同步,往往披星戴月即使勉强赶出压测结果大家也会弄得身心俱疲。

测试铺量阶段:1.前期时间允许的情况下,根据玩法的功能模块和实现预期写下用例后续。很赶的情况至少得梳理下个人玩法的基本功能模块如思维导图;2.快速做一遍冒烟测试,尽快推进代码或者配表上阻塞性的问题,美术资源没到位时也及时跟进测试进度。此时还可以督促负责的策划进行玩法功能的验收顺带把体验上的优化单开出。3.按模块大批量地覆盖执行用例,自己尽量按玩家体验的⻆度去细节考虑各功能点。每个版本尽量把提交检查和bug验证收敛。每周主要风险点和bug多的模块在制作群@相关负责人。

回归上线阶段:完善调整用例,整体细致回归一遍玩法和投放奖励,避免版本迭代未知的改动带来的问题。跳出原本的思维多考虑一些边界情况以及其他系统功能耦合的情况。没有把握的情况下可以让有经验的同事帮忙进行下用例评审和交叉测试

2.

沉淀输出

在我们的测试工作中可以输出内容有不少,例如测试用例,测试报告,测试流程文档,工具平台使用文档,测试经验分享,事故分析小结等等。这里谈论是比较理想情况下,现实中大多同学往往会感觉到时间上来不及或受难于怎么写好分享,可能等当前的项目需求结束后不久便抛之脑后,“过了这个村没有这个店了”。首先,我认为沉淀输出应当“趁热打铁”,在平时的测试过程中就可以多做一些灵犀文档啊便签之类的记录,等需求项目收尾后正处于你最熟悉的阶段,在下一个项目开始前的空档通过之前测试记录截图等埋点工作整理输出一波。再者,我认为沉淀输出的理念应是“前人栽树,后人乘凉”。我相信大家都经历过交接一些同事的工作或复用需求项目时,若是没有之前的一些测试文档和记录,无异于重头走一遭。因此从我们自己做起,杜绝一些口口相传和两手一摊的坏习惯,把用例、测试文档、复盘反思等内容收拾起来,不仅是对后来的同学负责,这也是项目组一份宝贵的经验传承。最后,还有个实打实的好处是当你填绩效自评或者写晋升PPT时,这些沉淀输出都能成为你的剑和盾,在职业发展上无往不利。

再往情怀上说,干QA一年三年六年十年,忙前忙后总得留下一些脚印。此去经年,忆往昔时也能看到记忆的沙滩上闪闪发光,抑或是看到当年内容浅笑自己幼稚,同时也⻅证记录了你这些年专业能力上的足进步

3.

游戏体验

问起你选择当游戏测试的初心,谁当时不是怀揣着对从小对游戏的热爱或沉溺呢?甚至很多同学在某些游戏体验上是⻣灰级的,打过比赛成就荣誉不输半职业选手。多年来和很多同学私下交流过平时喜欢玩的游戏,不难发现我们所在的项目游戏类型可能并不是自己最钟爱的,若你恰好在自己喜欢的游戏项目工作,不用怀疑你就是那个幸运儿,真是羡煞旁人也!若是兴趣上不匹配也很正常,人生不如意事十有八九。无论是干一行爱一行,还是爱一行干一行,首先测试是一份值得你认真对待的工作,对自己项目的游戏一点都不熟悉的话,那对我们后续的工作开展和沟通成本上的都会形成严重阻碍。因此在保证自己的业务工作完成之余,对所在项目游戏基本系统和功能玩法都比较了解熟悉,在测试过程中也有助于不同功能间耦合的情况也能及时考虑,触类旁通,举一反三。


04 普通QA的心态调节

没有人永远能保持积极乐观上进,每个人或多或少都有惰性和沮丧难过的时候。而我们作为一线执行业务的普通QA,要学会适时调节自己的心情和思绪。

1.

面对工作重压

干QA的几乎都经历过那埋头苦测半夜园区打卡发朋友圈的时光,无论是项目上线前的不舍昼夜,还是资料片赛季更新前的彻夜鏖战,可能你在承担重任的同时还会有其他工作需要多线程并行。耗时、棘手、头秃,那一重重的焦虑席卷而来真是令人窒息啊。当工作陷入困境,无从下手进度缓慢时,不妨停下蹒跚步履,稍微放空下自己,工作有时候真的是做不完的。通过一些运动、音乐、倾诉等方式,调节好自己的情绪,把手头工作重要度和完成时间节点排下优先级,然后逐一拆分,细化成一些小目标逐步进行,每天朝着小目标而努力,不用硬抗身体和精神的疲累,但是至少将今日目标完成个七七八八,带点成就感和充实感循序渐进下终能更好地完成整体的工作。真的扛不住的时候偶尔摆烂一下可以,切忌一拖再拖。万事开头难,当你努力迈出第一步时,已经是成功的一半了。

2.

面对事故定责

说到事故,说到补丁,责任上QA很难不牵扯其中。
当你新人阶段第一次遭遇打补丁时,心慌内疚不亚于拿破仑遭遇滑铁卢吧。或者遇到一个对线上影响严重的事故,也曾忐忑怀疑自己的职业生涯是否戛然而止了。最近几年我一直负责测试组内的事故分析的工作,也给校招新人做过这方面的课程培训,对事故的定级标准心中有尺。长期接触和观察同事们对patch的应对和态度,从中我也有了一些小小的见解。首先,从心理上只要人犯错,紧张窘迫和逃避的心理都是可以理解和被接受的。那应当如何去面对呢?我觉得我们干QA,玩法需求的质量根本上好坏并不是由QA决定的,QA的职责更多的是预防风险找出一些漏洞。因此面对事故,我们首先要客观接受,积极跟进处理,事后从中分析出问题的原因,吸取教训并落实今后避免的方法。对于一个线上运营的产品来说,事故越早修复对于玩家的影响体验以及舆论⻛险都会及时下降,相比对产品的影响和损失来说个人的一些定责和绩效的扣除我们应该谦逊坦然地去接受。对于QA个人而言,我认为经验上考虑上覆盖的不足导致的事故都是可以被谅解的,反而有些粗心犯的低级错误或者重蹈覆辙的事故是说不过去的,是时候给自己敲敲警钟了。

3.

面对团队氛围

刚进入一个项目组工作时,一切就像大世界一样充满未知和冒险及探索的乐趣。带教你的导师谆谆教导,年龄相仿志趣相投的同事一起去⻝堂干饭,一起讨论工作互相进步,一起谈天说地游戏开黑。仿佛更像是回到读书时代的欢乐时光。慢慢地呆得时间久了,某一天管你的领导突然换了,一路帮助你的师父远走,或者你熟悉的合作过的一些同事会悄然离开项目,甚至离开网易。其实每个人都有自己的发展和选择,山不转水转,互联网人从业流动本就是常态。初闻时心中难免讶异,我觉得我们更应该慢慢接纳这种变化,送上祝福和寒暄,关系要好的今后可以保持联络。也许短时间内项目的氛围会有些压抑沉默,但我们还是要继续做好自己负责的工作,项目的⻋轮还是滚滚向前浩浩汤汤的,当你感到夜幕即将降临时,不用悲伤,不必沉默,黎明总会到来,太阳也会照常升起。

再谈论下对不同职能间的看法吧,需求上合作最紧密的包括策划、程序、功能测试、测开。和组内的同学交流时不难感觉到一种刻板印象:从地位的高低来说,策划>程序>测开>功能测试,或者说什么甲方乙方。更早前我也隐隐带这种偏见和局限,习惯于把QA放在卑微的低姿态的一个位置上,这样的眼光对后面合作的开展是不健康的,如何正确看待不同职能的关系呢?首先在合作上大家是一个整体小团队,随便一个环节出问题,一荣俱荣一损俱损。其次,每个职能之间都是平等的,相辅相成的,没有什么优劣之分。比如策划主要是统筹进度和决策,QA可以助其预防一些投放风险提出优化建议;程序用专业的编码能力实现需求功能,QA可以助其找出漏洞以及设计上未考虑到的一些情况;测开和功能测试也是互相配合的,就如最近看过一个剧《我的人间烟火》,测开就像消防支队的指战员、培训师,功能测试就像十里台消防站的救火战士,每一场火灾的抢救都离不开双方的努力。测开主要负责压测脚本实现、性能⻛险的评估,平台工具的实现,功能测试也可以具备自动化的思维,主动提自动化需求给测开,还可以在应用工具平台提出使用反馈。总而言之,QA可以通过自己的专业能力和责任态度在合作中项目中慢慢提升自己的个人影响力,说话发声时才能有理有据,得到其他合作的同事信服从而改变“人微言轻”的错觉吧。


05 写在最后

通篇大论叨叨絮絮,没有引经据典也没有生动有趣的举例,都是本人抒发的一些拙见。每个人对工作的看待都不尽相同,有人觉得工作就只是工作避免过多精神内耗,有人通过努力认真工作养家糊口,有人兢兢业业为之奋斗成就颇丰。而选择当游戏测试的我们,作为一个普通QA来说,或多或少总是有所收获的,接受过批评也罢,得到过认可也好。从业开始经历的日日夜夜,静躺在项目中开出的成千上万的BUG单,细致分析的事故,苦思冥想写出的分享,都见证着你在普通的某天里努力挥洒的汗水。

我很喜欢冰心的一句小诗,“墙⻆的花,你孤芳自赏时,天地便小了”。

作为普通QA的我们,要试着自我欣赏和自我肯定,因为当好普通QA,本身就是一种平凡的伟大






推荐阅读



如何建立系统性的闭环思维


从“盒装产品”到“实时服务”的思维转变


从测试到质量--不同业务特色下的质量保障




 

都看到这里了,点个赞再走吧~

网易雷火测试中心
雷火测试中心致力于提供高质、高效的质量保障服务,建设成为国内顶尖的测试团队!
 最新文章