聊一聊职业发展

目录

老生常谈,再谈谈测试职业发展

有这么个普遍现象

测试招聘者,特别是一、二线互联网公司的招聘者最苦恼的事儿就是招人。想找到一个合适的人难于上青天,每天各种撒网,简历看几百份,面大几十人,能捞到一个中意的小伙伴就谢天谢地了。但同时很多测试小伙伴发现找工作很难,特别是进大一点的厂,他们特别挑:代码要会写,要有软件架构能力,问一大坨平时根本用不到的技术问题,还挑经验,挑沟通能力,挑这挑那,有时候还特么挑学历、挑年龄。。。 供求总难以匹配起来,造成了双方都很痛苦。

Why?

能力要求不匹配是最核心的问题。软件、互联网近20年来飞速成长,其实也经历了很多阶段。行业软件兴盛阶段和外包兴盛阶段(2000-2010年)行业进入了大量的测试人员,当时最主流的测试实践是:重心放在系统验收阶段。测试人员的主要工作基本都投入在了基于业务的黑盒测试上,对代码能力、系统理解的能力要求不多。2010年后,互联网行业的真正兴起让国内软件开发模式开始缓慢调头,快速迭代的模式逐步兴起,开发周期越来越短,迭代越来越快,但系统越来越越庞大、复杂。原来的测试工作模式和工作范围越来越无法满足要求了。但大量从业人员技能范围转变是一件很难的事情,行业是有巨大惯性的。从宏观上看大量QA技能转变跟不上需求转变是造成市场供求不匹配的主要原因

So What?

三个观点:1. 只做手工测试,不懂系统实现的测试工程师的职业发展会越来越受限。2. 能够转型成适应市场需求的同学将在近几年的时间获得超额回报(因为市场供不应求,企业不得不抬高价格来寻找这样的人)。3.对于个体来说,自我成长永远最重要,自己永远要对自己的发展负责,别依赖外部环境,自己想办法变成市场的香饽饽才靠谱。

到底什么样的人抢手?

按照我一点理解讲一讲什么样子的人会抢手吧,限于篇幅会偏重技术角度来讲。个人之见,欢迎讨论和拍砖。

高段位要求(高级职位需求)

例子2:上面的问题,除了环境,还有一个槽点:开发提测质量不高。测试的头几天,很多主流程都走不通,导致测试总是在等待,或者是跟着开发一起联调。而这段时间,已经被习惯性的认为是测试时间了,因为:提测了。

你推动了:测试提供冒烟用例,开发必须完成一定程度的自测才能提测。
你推动了:测试和开发做自动化同期共建,在开发过程中,核心功能就被自动化用例保护起来了。
你推动了:开发切分feature提测,而不是攒一个大招一下子提一坨。
你推动了:代码Codereview变成团队常规活动,QA在早期跟进核心代码,把问题坑杀在萌芽阶段。
你推动了:外部资源联调非常早的进行,不会让它在测试后期成为测试blocker。
。。。

例子3:你发现测试时间长,QA自己也有问题。

你推动了:有明确的测试计划,并让所有干系人都有明确的预期。
你推动了:测试依据风险测试,最大的风险得到最快的cover,科学分配时间,明显缩短bug反馈时间弧。
你推动了:bug严格管理,所有重要bug都及时修复。
你推动了:良好的沟通和汇报机制,每天让团队主要干系人清晰的知道,距离发布还差多远。

你推动了。。。。

你能讲出自己做过5个以上这样的成功例子,我敢保障,你会被1线大厂疯抢。职级基本都是专家起。

例子1:
你近期的工作是帮助团队提升后台服务稳定性。你看到了netflix内部使用一个叫做ChaosMonkey的东西来随机对生产服务期进行攻击,而逼迫工程师提高稳定性,所以,你也实现了类似(更温和)的内部机制,推动团队稳定性的提高。
你怎么知道这个叫做ChaosMonkey的东西呢? 因为你会习惯性浏览一线厂商的技术博客,参与行业大会,关注各类新技术。持续性的养成习惯。

例子2:
做大规模接口自动化好难,外部数据依赖太难搞,参数构造太费劲,assert太难写。如果能够简单的录制回放就好了。
但是,外部依赖是个天坑,写操作mock也是个天坑,assert也是个天坑。
实际的案例是,经过几年多个团队持续不屑的填坑,阿里内部已经有应用级的录制回放工具了,数百个应用成功的是用了它,把不可能回归的任务变成了可能(上万数量级的case当天生成,当天投入使用,并可以分析覆盖率),自动化测试实施需要付出的工作时间革命性降低(不足原来付出时间的10%)。

你能讲出自己做过5个以上这样的成功例子,我敢保障,你也会被1线大厂疯抢。职级基本都是专家起。

怎么转型/怎么进阶?

其实不难,没有什么高端的方法。下面这4条就够了,核心秘密就是坚持不懈

看到有同学说要裸辞,去接受培训。我的建议是,别这样。裸辞你就失去了学以致用的阵地,失去了真正解决问题的机会,还失去了资金来源。依托工作,自主学习是王道。自己饶过不去坎,其实有很多网上教程和非脱产培训班啊。

总结

偏重技能角度讲了讲市场的需求和QA如何做如何满足市场需求。行文仓促,认识有限,其实也并没有什么新东西。欢迎讨论拍砖啊:)

最后放一篇老文,前google测试总监写的,写了快10年了,但我觉得常读常新。

顺手发个招聘广告

我的team在招聘QA小伙伴。地点北京,技术职级P6或者P7 。 P8也有可能(只要你足够强悍)
偏后端测试,有意者请邮件我啊 daohe.lxg@alibaba-inc.com

———————————————————–我是分割线——————————————–

经营成功的测试职业生涯

(James A. Whittaker)

你是如何开始做测试工作的?

1989年,我在田纳西大学读研究生的时候,完成了从软件开发人员到软件测试人员的转型。而这一转型并非出于我自己的选择。我命运的改变发生在一个早晨,我的教授质问我为什么缺席那么多开发会议。我解释说因为会议被安排在星期六早上,很不方便。

而怍为一个生平第一次离开家的新入校的研究生,这个时间段有些麻烦。十分有意思的是,等待我的惩罚并不是一纸解聘通知书,而是被判罚为该小组的唯一一个测试人员,且不能与开发团队有任何交流。

对于我的职业生涯来说,这是一个意义多么重大的决定啊!正是这个决定最终成就了几十篇关于测试的论文,构建了多得连我自己也记不清的各种工具,出版了五本书,带来了无尽的快乐工作时间。测试一直就是我拥有的那份具有创造性和技术挑战性的快乐职业。不过,并不是所有人都喜欢这样。可以说我最早接触测试是在攻读研究生期问,不可否认,那时的高强度学习和工作确实让我受益匪浅。另外,我认为从初学者阶段到专家阶段之间存在着一个“测试的山峰”,人们需要通过一系列个人辅导、获取信息和接受常规指导来翻越山峰。成为一个测试初学者是很容易的,成为职业的测试人员也并不艰难。本章的重点正是讨论如何翻越那座位于职业测试人员和测试专家之间的山峰。

回到未来

在软件测试领域,时间似乎已经停滞了。我们在21世纪做事的方法与上个世纪几乎完全相同。Bill Hetzel在1972年出版的测试知识丛书至今仍然相当有价值。而我自己所写,于2002年首次出版的How to Break Software(如何攻破软件)系列,到今天仍被作为实用软件测试技术主要资源的代名词。

确实,如果我们可以把20世纪70年代的测试人员转换时空用在今日,我猜想他们的的技巧足够应付现代软件的测试。当然,他们需要学习网络和各种网络协议,但是他们拥有的实际测试技术将能得到很好的应用。如果从20世纪90年代找一个测试人员,则不几乎不需要任何训练。

对于开发人员来说,却不是这样,他们所掌握的那些上世纪的技巧几乎已经完全过 时。让一个有一段时间不写代码的人重新开始编程,看看会有什么样的反应。让我感到很不安的是,我们可以从马路上直接雇用人手,而雇来的这些人从第一天起就能够测试,就能够有收获。事情真的有那么简单吗?或者是我们的期望值只有那么低?让我更加不安的是,我们没有任何可预测的方式将合适的测试人才从胜任工作状态训练为测试专。测试真的就那么困难吗?

这又是那个山峰了。门槛很低,但通往精通的道路却很艰难。

在通往测试山峰的入口,我们倚仗的是这样一个事实:测试的很多方面都很容易掌握。大多数人都可以学得有模有样。甚至只要将一点点常识应用于输入的选择,就可以找出缺陷。这个层次的测试就如同在桶里钓鱼,简单到足以让任何人都认为自己很聪明。然而过了入口以后,道路迅速陡峭起来,而测试知识变得越来越晦涩难懂。我们发现有人擅长于此,我们称这些人为“有天赋的人”,并欣赏他们的本能。

难道一定要依靠本能么?对于那些看起来不具备特长的人们,是否存在着一条翻越山峰的途径?是否可以以某种方法传授测试技能以培养出更多的专家呢?为认为这座山峰是可以通行的,而这一章正是我关于应该如何走这条路的笔记,你可以在自己的职业生涯中加以应用。这并不是一份食谱配方,一份职业生涯烹调书。不过你可以做一些事情来加速你的职业成长。但是,正如你可能已经猜到的,真正是说来容易,做起来难。

上山

测试职业的早期阶段主要是为征服测试山峰的漫长攀登做准备。我所能给出的最好的建议是从两个方面来思考问题。对于你参与的每一个项目,都有两部分(不一定相等)的任务。第一部分的任务是保证当前的测试项目获得成功。而第二部分的任务是学习你应该做些什么以便使下一个测试项目更加容易。我把它称为“测试今天的项目,准备明天的项目”。如果你做每一个项目把它都分割成为上述的两半,那么几乎可以保证你能持续获得进步。这样,你就可以随着每一个参与的项目逐渐成长为更优秀的测试人员。

现在就让我们来关注第二部分的任务——为下一个项目做准备。我们需要注意三个概念:重复、技术和漏洞。

重复

做任何一件事,绝不要重复两次而不意识到或质疑这其实是个问题。我希望所有年轻的测试人员都牢记这一点。我见过很多初学者,他们在单调的任务上浪费了太多的时间,比如,设置测试机器,配置测试环境,在实验室里安装待测试的应用程序,选择一个产品版本来测试-这些任务列表可以变得很长,最后你会发现真正花在测试软件上的时间少得可怜。

这是许多新手常犯的错误。他们没能看到他们日复一日所做的工作的重复本质,儿当他们意识到这种重复时,几个小时已经过去了,而在这几个小时内他们没有做任何实际的测试工作。关注这些重复劳动,并且留意由此造成的真正的软件测试工作时间的流逝。为了能翻过测试的山峰,必须做一个测试人员应该做的工作,而不是实验室管理员或者测试机管理员的工作。

测试自动化是解决重复劳动的方案,也是本章稍后的主题。

技术

测试人员常常会对软件失效进行分析。分析缺陷时,我们从开发人员的失败中学习如何编写可靠的代码。我们也分析那些被我们忽略的缺陷。在应用程序上市以后,客户就会开始报告缺陷,我们将要面对处理一大堆失效的情形并寻找其中的重要缺陷。用户报告的每一个缺陷都说明我们的流程有问题,我们的测试知识还不够完善。

但是分析我们的成功也同样重要,儿许多新入职的测试人员却没能利用这个唾手可得的资源。我们在测试中找到的每一个缺陷都说明我们的的测试流程正在有效工作,都是一次成功。我们需要紧紧抓住这种绝好的机会,只有这样才能使成功不断的重复下去。

运动队常常这样做,他们会观看比赛录像,并分析每一个动作为什么奏效或者为什么不奏效。我清楚地记得一个小故事,我的一个朋友拍下了我儿子踢足球的一些照片。其中一张照片记录了她踢球的瞬间,那个球超过对方守门员成功进球了。当我把它给我儿子看时,我之处他站立的那条腿的姿势非常完美,他踢球的脚尖紧绷且出球点在鞋带间恰到好处的位置上。他盯着那张照片很长时间,从那以后他很少用不正确的姿势踢球。他那次得分可能只是碰巧做对了,但从此以后他有意识的运用这些技术使之接近完美。

现在回到新手测试人员的课程上来。我们每一个人都会有得意的时刻。我们找到重要的漏洞或发现优先级很高的缺陷,并为此雀跃不已。不过先花点时间考虑一下整体状况。我们使用什么技术找到了那个缺陷?我们是否可以创建一种方法来找到更多这类缺陷?我们是否可以记住…些实际的测试经验并不断地加以应用来帮助提高我们的工作效率?软件的哪些症状可以提示我们它具有缺陷?我们将来能否从那些症状中得到更多的警示?换句话说,这不仅仅是一个缺陷或是一次成功,这个缺陷教会了我们什么,是否使得我们将来成为更好的测试人员正如我儿子的进球一样,尽管第一个缺陷是偶然间发现的,但它不代表其余的成功都是偶然。理解我们成功的原因很重要,只有这样做,成功才能被复制。对于测试人员来说,这种保证成功的原因就是一系列的测试技术、建议和工具,它们可以提高我们在未来项目中的工作效率。

漏洞

测试人员最终都会变得很擅长寻找缺陷,但是要翻过测试的高峰,我们必须更快并且更有效率:高速低阻。换句话说,我们必须拥有一种本身不含缺陷的缺陷查找技术!

我喜欢这样来考虑问题:测试人员检视自己的工作时也需要发挥那种寻找缺陷的能力。我们必须使用和寻找产品缺陷一样的流程来寻找我们自己的测试流程,测试过程中的缺陷。我的测试流程是不是有问题?这里面是否有缺陷?这里是否存在着妨碍我提高效率的障碍?

你必须一直寻找更好的方法。有意识地去确定那些限制能力、阻碍前进、减缓速度的东西。就像缺陷限制了软件满足用户需求的能力一样,是什么限制了测试的能力?使用你拥有的测试能力来最优化自己的测试流程,这会帮助你在测试的山峰上快速攀登并增加你翻越山峰后成为专家的机会。

测试山峰的巅峰处是一个美好的地方。如果你成功地到了那里,恭喜你.但这并不是最终日标。这表示你已经成为一个杰出的测试人员。而此时的下坡路就是用你的洞察力和专家知识来帮助周围的人也成为优秀的测试人员。自己一个人登顶是一回事,帮助其他人(那些能力不如你的人)登顶却完全是另外一回事。

一般来说,那些成功登上测试巅峰的人会成为使用工具的大师。那些商业工具、开开源免费工具,和自己写的工具(我个人最喜欢的工具)是极好地提高工作产出、增加工作成效的方法。不过,工具只是实现该目标的一种方法,但在许多其他方面它反而是一种限制,因为太多的人看不到工具的功能之外的东西。他们被限制在工具能为他们所做的事情中,没能看到或理解对工具还有更多的需求。登顶需要真正掌握的是“信息”。因为很多工具能处理信息,并使得信息的获取更加容易,所以测试人员变得过于依赖于他们的工具。但是信息本身以及如何利用这些信息才是真正的成功关键。

熟练掌握信息,指理解有哪些信息,这些信息将如何影响测试,保证最大限度地利用这些影响。有几类信息是测试登顶者必须关注的。这里我要谈的是其中两种:来自应用程序的信息和来自之前测试的信息。

来自应用程序的信息包括需求、体系结构、代码结构、源代码……甚至是关于应用程序在执行时做了哪些事情的运行信息。在编写和执行测试用例时,需要考虑这类信息,但信息的多寡在很大程度上取决于测试人员的能力,这是一种能够使测试更高效的能力。在测试中使用这类信息越多,测试就越偏向于工程而不是猜测。

在微软,我们有一个游戏测试组织(Games Test Organization,GTO),负责Xbox和PC游戏的测试。谈到利用应用程序的信息,他们是最优秀的。游戏是难以想象的丰富,测试起来非常复杂。游戏中很多可测试的内容都是隐藏的(因为让那些玩家找寻可以交换的物品正是游戏的乐趣之一)o如果GTO的测试人员所做的仅仅是玩游戏,那么他们找到的问题不会比最终用户更多。为了能做得更好,他们与游戏的开发人员合作创建了一些信息控制板,这些控制板暴露了一些基本上可以算得上作弊的信息给测试人员。这样,测试人员就能提前知道怪物会被投放在何处、物品被隐藏在哪里,他们可以看到墙的另一边,可以控制敌方的某些行为。他们的作弊工具(即测试工具)基本上使他们成为游戏里的神,让他们可以控制看到的信息以便更快更巧妙地测试。这个例子给有测试人员都上了一课。

来自测试的信息意味着你必须关注在测试时所做的一切,并使用获得的信息来影响今后的测试。你是否知道你的测试是如何与需求结合的,知道何时某一特定需求已经得到足够的测试?你是否使用代码覆盖率来影响未来的测试?你知道当代码更新或缺陷修复时那些测试会受到影响,还是知识重新运行所有的测试?理解测试进行到什么程度并随着测试调整测试策略,这是测试成熟的标志。

我以前曾在微软的Visual Studio的一个小组工作过,我们大量使用代码改动量(由于添加新特性或修复缺陷而改变的代码)和代码覆盖来影响我们的测试。我们花了很大的力气将代码覆盖和代码改动量通知测试人员,帮助他们理解哪些测试用例对覆盖率有贡献,帮助他们测试改动过的或修改过的组件。最终的结果是在代码确实被改动时,我们清楚地知道哪些测试会被影响而只重新运行那些测试。我们还知道每个新的测试用例是如何对总体的接口,特性和代码覆盖率产生作用的,从而指导我们的测试人员,让团队中的每个人在他们所创建的所有测试用例基础上,写出更有意义的测试。

你用哪些信息来指导你的测试?你如何保证信息是可获取的,以便在测试中随时可以得到?你如何使得信息变得有用,以便它能以良好的方式影响你的测试?这些问题的答案将决定你在走下专家测试山峰时的前进速度。

下山

到达测试山峰的顶峰的时候,你已经成为一个十分能干的测试人员了,能力也许相当于你组里所有同事能力的总和。无论你在做什么,请不要试图做得比你的整个团队都好,不管你对此感觉有多好,或是你的老板对你遏得有多紧。一旦你走在下坡的路上,就不要再去争取“找到最多缺陷的人”或是“找到最有意义缺陷的人”这样的荣誉头衔。反而我推荐你减少花在测试上的时间,而把创新作为你的首要任务。

在测试上创新指不急于向前,而是仔细观察、洞察先机、找到瓶颈并改进团队中所有其他人的工作方式。你的工作变为帮助其他人进步。在微软,我们有一个专门为此而设的正式职位——测试架构师。不过,不要因为缺少一个很酷的头衔而让你沮丧。无论别人怎么称呼你,当你在“下坡的路上,你能做的最好的事就是尽量保证更多的人能成功地爬上山峰的另一侧。

原文地址:
https://testerhome.com/topics/16354