测试架构师修炼之道:从测试工程师到测试架构师(txt+pdf+epub+mobi电子书下载)


发布时间:2020-06-07 23:04:41

点击下载

作者:刘琛梅

出版社:机械工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

测试架构师修炼之道:从测试工程师到测试架构师

测试架构师修炼之道:从测试工程师到测试架构师试读:

前言

为什么写这本书

先讲两个故事吧。

一次我面试了一位有8年名企测试经验的候选者。面试中,我能感受到他对他现在做的业务很熟悉,但他熟悉的这些业务和他现在申请的职位中涉及的业务相差甚远,于是我就问了个问题:“如果我们有幸能够邀请到您加入我们的团队,您可以给我们团队带来些什么呢?”这位候选者竟然语塞——尽管他拥有8年的测试经验,但是除了业务知识,对测试本身,他却几乎没有任何思考和总结。一旦离开了熟悉的业务领域,他就又回到了“新人”的状态,之前的经验很难复用,需要重新积累。

不过这件事情更触动我的是在面试结束后和我一起面试的另一位面试官(这是一场“二对一”的面试)的话,她说她感到有点害怕,害怕8年后她也会陷入这位面试者这样的状况……

第二个故事也是面试中的故事。一位有4年名企测试工作经验的候选者,已经开始在大公司里面做测试管理了。我们谈到了对测试技术的理解,他开始谈当前公司的流程,谈得很好。我接着他的话题,提了个问题:“您会在什么时候、从哪些角度去识别测试项目中的风险?以及如何处理这些风险?”这位候选者的答案是:“我们的风险就是项目延期,其他没有风险,流程上写得很清楚什么时候要识别风险,到了那个时候我们就把这个问题提出来,发邮件给大家,包括各个领导,请他们来解决。因为这个问题我们也解决不了。”显然,他一直在被所谓的厉害的“流程”牵着鼻子走,流程中蕴藏的测试理念、方法和实际工作已经无法落地了。

这两个故事,引出了一个值得我们思考的问题:什么是测试的核心?

作为测试人员,掌握“业务知识”是必须的,但是“业务知识”并不能和“测试能力”画等号。“测试流程”或者说“测试管理”对测试来说很重要,但是否只要严格遵循它们就能做好测试了?如果上述答案是否定的,那么什么才是测试的核心?我们又该如何去积累沉淀这方面的技能?这就是我写这本书的初衷——想和大家来分享我对“测试核心”的思考,分享这其中的技术总结。1. 测试的核心是什么?

我认为测试的核心不是业务、测试方法、测试设计、自动化、测试管理、测试流程等,而是“测试策略”。

我们该如何理解测试策略呢?测试策略通俗来说就是“测什么”和“怎么测”,大致包含了如下内容:

· 测试的对象和范围是什么?

· 测试的目标是什么?

· 测试的重点和难点是什么?

· 测试的深度和广度如何?

· 如何安排各种测试活动?(先测试什么,再测试什么)

· 如何评价测试的效果?

这就需要我们基于“产品的质量目标”,基于“风险”,在充分考虑“产品研发状况”的前提下来安排各种测试活动,在有限的时间里进行“刚刚好”的测试。这也正是本书想要讨论的主要内容。2. 这本书的价值是什么?

本书讨论的主要内容是“测试策略”,虽然现在已经有很多优秀的测试类书籍,但是讨论测试策略方面的书籍却比较少,本书可以为读者在测试策略的制定上提供很有价值的参考。

本书也讨论了测试设计、测试方法、缺陷分析、质量评估等大家熟悉的测试技术,本书还使用了大量的篇幅来讨论如何在工作中使用这些技术,制定出如何适应实际情况的策略,来使测试更为有效。

另外本书还提供了一些有很强实用性的模型模板和checklist,读者可以直接在产品中使用。本书的主要内容

本书以“软件测试架构师”为线索,分为三个部分。

第一部分,瓶颈:软件测试工程师该如何进行职业规划。从当前软件测试行业的普遍困惑入手,对中国的软件测试行业、软件测试职业现状进行分析,给出软件测试的职业规划建议。特别指明了软件测试工程师在技术上的发展方向——软件测试架构师。为软件测试架构师画像,讨论作为软件测试架构师在测试过程中需要关注和不需要关注的内容。

第二部分,突破:向软件测试架构师的目标迈进。这部分又可以分为两部分,即软件测试架构师需要掌握的基本测试技术和软能力。

其中需要掌握的基本测试技术包括:

· 软件产品和质量模型

· 测试类型

· 测试方法

· 测试设计

· 探索式测试

· 自动化测试

软能力包括:

· 沟通和协商

· 写好测试用例的技法

第三部分,修炼:软件测试架构师的核心技能。在这一部分,我们首先介绍了与测试策略相关的技术:

· 四步测试策略制定法

· 产品质量评估模型

· 测试覆盖度评估

· 测试过程评估

· 缺陷分析技术

· 风险分析技术

· 分层测试技术

然后具体讲解,如何运用这些测试策略编写技术和基本测试技术,包括我们的测试软技能,来制定总体测试策略、阶段测试策略;如何制定版本测试策略和对产品质量进行评估,以及在质量评估中发现问题时,该如何修正测试策略。本书的核心思想

· 中国软件测试行业整体起点较高,但对软件测试却普遍缺乏理解和认识。认为软件测试没有或者缺乏技术含量的居多,其中不乏领导或决策者。

· 软件测试在技术上可以向软件测试架构师发展,成为产品测试专家。软件测试架构师是产品测试的灵魂。

· 软件测试架构师需要像系统架构师一样理解产品的商业目标和用户的使用场景,要从整体上来把握测试节奏,为团队的关键测试活动(如测试设计、测试执行)提供辅导。要保证测试策略能够在整个团队中落地,而不是自己挽着袖子上。

· 软件产品质量模型是测试的基础。测试类型、测试方法都是在此基础上衍生出来的。

· 测试点不等于测试用例。测试点通过测试设计来得到测试用例。

· 软件测试架构师虽然是测试团队的技术官,但是也不应该忽视沟通协商和文档写作方面的能力。

· 测试策略是测试的核心。

· 测试应该基于质量目标、基于风险,围绕研发流程,通过分层来进行“刚刚好”的测试。本书的独特之处

目前已经有很多优秀的软件测试书籍,其中不乏精品,但是我发现这些书籍大多只是单方面地讲授软件测试理念和基础,或是单方面地讲授某种测试技术。本书则规避了这一点,并不单方面讲授理念或技术,而是通过“测试策略”把理念和技术串起来了,教大家该如何来确定测试目标,确定测试范围,确定测试深度和广度、重点和难点……你可以很容易将书中的内容运用到实际工作中去。

本书的另外一个特点是书中使用了5个高度概括模型:四步测试策略制定法、软件质量评估模型、四步测试设计制定法、测试方法车轮图和两份checklist(风险分析checklist和老功能分析checklist)。有了这套模型工具,我们就可以对软件测试工作进行系统思考了,这样有利于我们对自己的工作进行总结,突破“瓶颈”。

不同于一般的测试书籍,本书在行文安排和编写视角上也别具特色:从测试的职业发展规划入手,为软件测试架构师画像,为测试者指出测试技术上的奋斗方向;然后介绍软件测试架构师需要掌握的测试技术(除了我们熟悉的测试设计技术、缺陷分析技术外,本书还特别编写了沟通交流、文档编写等软技能);最后介绍如何使用这些技术来编写测试策略,在整个测试过程中需要设计、安排哪些测试活动以进行“刚刚好”的测试。可见本书并不是以技术为主线来编写的,而是围绕“软件测试架构师”,即“人”来展开的,我希望这样的设计能够让读者在阅读本书的时候感到更为生动和实用。本书适合谁看

本书比较适合有一定经验的软件测试工程师,以及希望在测试技术上有所发展的测试人员阅读。

当然,如果您是一位初涉测试的朋友,本书在测试职业规划方面的描述、测试技术方面的总结和叙述对您来说也会是不错的参考。如何使用本书

如果您是一位有一定测试经验的软件测试工程师,目前感到在测试技术或测试发展中出现了“天花板”,有些迷茫,那么本书就再适合您不过了。建议您不要跳过一些章节,而是按顺序阅读,相信本书一定能帮您答疑解惑,使您找到自己新的发展方向,而且本书也能帮您找到突破点并在测试领域能够有突破。

如果您已经是一位软件测试架构师,那么本书的第一部分,特别是第1章和第2章,建议您直接略过,推荐您重点阅读本书的第三部分。对于本书的第二部分,您可以选择感兴趣的章节参考阅读。

如果您是一位初涉测试的朋友,建议您重点阅读本书的第一部分和第二部分,参考阅读第三部分。勘误和支持

我由衷热爱自己所从事的职业——软件测试。很高兴我已经为此奋斗了10年,并很愿意再为此奋斗第2个10年、第3个10年……我写这本书的目的很简单,就是想分享我的经验、我的思考和我的总结。但由于我的水平有限,编写时间仓促,书中难免会出现一些错误或不准确的地方,恳请各位读者批评指正。当然,如果您在阅读本书时有任何问题,也欢迎提出来,我将尽量为您提供最满意的解答。

我的常用邮箱是:76994738@qq.com。

微信:meizi0103。致谢

首先要感谢的是我工作时的第一位导师赵金明先生,谢谢赵先生将我带上了软件测试这条路。感谢我在软件测试之路上遇见的几位前辈,谢谢你们对我的指导和培养。还要感谢我的小伙伴、大伙伴们,谢谢你们对我的支持和帮助。

当然,我最要感谢的是我的妈妈、我的爱人和那些默默关怀我的人。在决定写这本书之前,我从来绝不会想到写书是一项如此艰难的工作,在我多次想放弃的时候,是你们让我变得勇敢、坚强,敢于坚持自己的理想,谢谢你们对我因为写作而无法陪伴你们的理解。

当然还有机械工业出版社的杨福川和孙海亮,感谢你们在我自己都快放弃的时候,还能对我不抛弃、不放弃,感谢杨福川策划对本书编写提供的非常专业的建议,感谢孙海亮编辑在我写作陷入困境时的悉心帮助和指导,真心地感谢!我唯有回馈努力、感恩和祝福!第一部分瓶颈:软件测试工程师该如何进行职业规划

· 第1章 软件测试工程师的“三年之痒”

· 第2章 软件测试工程师的职业规划

在中国,软件测试其实很年轻,但是软件测试行业的发展却非常迅速,不仅软件测试工程师的数量与日俱增,而且各种和软件测试相关的技术也层出不穷。在软件开发项目中,软件测试也越来越受到重视,开始扮演越来越重要的角色。

但是我们也需要注意另外一个现象:软件测试工程师工作两三年后,会逐渐发现自己遇到职业发展的“瓶颈”,我们姑且称之为“三年之痒”。具体表现为:软件测试工程师觉得自己基本的测试技术已经掌握了,对产品也比较熟悉了,但是不知道该如何深入,工作开始缺乏挑战性和成就感。

本来在职业发展的过程中,遇到“瓶颈”也是很正常的事情,但是对软件测试工程师来说,似乎更难突破。和各种“痒”一样,当前行的动力只剩下了“惯性”时,软件测试工程师就容易变得迷失、焦虑和痛苦,“痒”就变成了“坎”。很多优秀的软件测试人员在这个时候选择了离开或者准备离开;各种技术论坛、博客上也不乏“软件测试无技术”“软件测试无前途”的论调,软件测试似乎成了一个没有多少发展前途的行业。

这是一个很奇怪的现象,一方面软件测试的队伍迅速扩大,一路高歌猛进;另一方面在软件测试面前又似乎横亘着一个迈不过去的坎。我认为,在这个现象背后有一个重要原因,就是软件测试在中国的发展过于迅速,反而导致从事软件测试工作的人们对软件测试的理解存在偏差,即使是软件工程师,对软件测试的优势、劣势认识也不足。当软件测试工程师遇到职业发展“瓶颈”时,就变得难以进行有效突破。

本书的第一部分将和大家一起更深入地去理解软件测试,探索软件测试的优势和劣势,理清软件测试的发展方向,并对软件测试工程师该如何进行职业规划提出建议。第1章软件测试工程师的“三年之痒”1.1 软件测试发展简史

其实从软件开发一开始,就有软件测试了。不过最初的软件测试其实只是“调试”,还算不上真正的软件测试,一般是由开发人员自己完成的,投入极少。

随着软件行业的发展,混乱无序的软件开发过程已经不能适应软件功能日益复杂的现状,从而出现了“软件危机”。1968年秋季,NATO(北约)的科技委员会召集了近50名一流的编程人员、计算机学家和工业界巨头,讨论和制定摆脱软件危机的对策。在那次会议上提出了“软件工程”的理念。随着软件工程的发展,软件测试也开始逐步发展起来。

1975年,两位软件测试先驱John Good Enough和Susan Cerhart在IEEE上发表了《软件数据选择的原理》,将软件测试确定为一种研究方向。此时软件测试普遍被定义为“证明软件的工作是正确”的活动,这个理念被简称为“证实”。

1979年,Glenford J.Myers的著名的《软件测试艺术》一书出版(此书到现在已经第三版,依然被大多数软件测试人员奉为经典)。该书结合测试心理学,对测试重新进行了定义,认为测试是为了“发现错误而执行的活动”,这个理念又被称为“证伪”。“证实”和“证伪”至今依然是软件测试领域重要的理念,对软件测试工程师有着深远的影响。

1983年,另一本软件测试的重量级著作——《软件测试完全指南》(Bill Hetzel著)横空出世。这本书指出:“测试是以评价一个程序或者系统属性为目标的任何一种活动,测试是对软件质量的度量。”至此,人们已经开始意识到,软件测试不应该仅是事后用来证明软件是对的或是不对的,而应该走向前端,进行缺陷预防。

20世纪90年代,软件测试开始迅猛发展。软件测试工具开始盛行,极大地提升了软件测试的能力,同时自动化测试技术也开始迅猛发展,各种对软件测试系统的评估方法也开始被提出,如1996年提出的“测试成熟度模型(TMM)”“测试能力成熟度模型(TCMM)”等。软件测试体系日益成熟完善。

2002年,Rick和Stefan在《系统的软件测试》一书中对软件测试做了进一步定义:“测试是为了度量和提高被测软件的质量,对测试软件进行工程设计、实施和维护的整个生命周期过程。”这一定义进一步丰富了软件测试的内容,扩展了软件测试的外延。

阅读软件测试的简史你会发现,软件测试的发展史其实就是一部探索“什么是软件测试,我们该如何理解它、发展它”的历史。软件测试从软件开发中的“调试”,到“证明软件工作是对的”,再到“证明软件工作存在错误”,再到“预防”,早已不再蹒跚学步、懵懂无知。软件测试已经逐渐形成了自己的一套体系,拥有自己的成熟度评价方法。随着软件开发的发展,敏捷、迭代等各种软件开发实践也给软件测试带来很多新的挑战,产生了更多软件测试的新技术和新理念。但是我们又发现,这份软件测试的发展简史,是一份“西方”的软件测试史,尽管各种软件测试技术层出不穷,但在软件测试方面,中国还是西方的跟随者。那么中国的软件测试行业又有哪些特点呢?下面我们将进行分析。1.2 中国的软件测试行业

概括来说,中国的软件测试行业有个很重要的特点,就是它的起点很高。但是中国软件测试的高起点似乎没有能够很好地持续下来。软件行业对软件测试的不理解(或是片面的理解)让软件测试陷入困境和迷局,下面我们将分别进行分析阐述。1.2.1 软件测试整体起点较高

随着中国软件行业的发展,在产品复杂度提升、软件产品工程化需求和对产品质量更高追求等内因的推动下,国内一些公司也开始成立独立的测试部,中国开始出现第一代软件测试人员。

中国的第一代软件测试人员走的并不是一条“一穷二白”的路,此时西方软件测试领域已经建立了较为完整的软件测试体系架构,各种软件测试理念和方法都可供中国软件测试人员学习参考,所以中国的软件测试在理论上的起点是很高的。

Marine L. Hutcheson在她的Software Testing Fundamentals:Methods and Metries(《软件测试基础:方法与度量》)一书中提到,在西方一些企业,“一个出色的分析人员在具有5年代码评审和编写设计规格说明经验之后被提升为编程人员,在具有5年的开发经验后,非常优秀的开发人员有希望提升到系统测试组中”。可见,在西方一些软件企业中,对软件测试人员的要求是非常高的,这些人员都有开发经验。这其实和中国的第一代软件测试人员的经历较为吻合:他们中有很大一部分都是从软件程序员直接转岗的,有一定的编码能力,对系统的实现细节理解深入。所以总体来说,中国的软件测试开了个好头儿,起点是较高的。随着测试行业的进一步发展,这批软件测试人员大都发展成了软件测试行业的领军人物。1.2.2 软件测试的困境和迷局

中国的软件测试虽然起点较高,但是软件测试的发展似乎没有想象中那么顺利。

其实每个行业除了有自身领域外,还有属于自己的“生态系统”。属于软件测试的生态系统主要包括后备软件测试人员、软件开发人员和软件管理决策者。后备软件测试人员是软件测试的生力军,为软件测试提供新鲜血液;软件开发人员是软件测试人员最紧密的合作者;软件测试并不是一个独立的行业,决定软件测试人员发展的并不仅仅是软件测试的管理者,软件管理决策者也参与其中。这构成了一条属于软件测试的生物链,如图1-1所示。图1-1 软件测试领域的生物链

在中国,这条软件测试生物链似乎存在一些困境。1. 后备软件测试人员对软件测试不了解

随着软件测试行业的发展,通过校园招聘,从计算机科学等相关学科的大学毕业生中招聘软件测试工程师成了招聘软件测试工程师的主要途径。但是国内能够提供专业的软件测试课程的高校并不多,大部分毕业生甚至从来没有听说过“软件测试”这个职位。在缺乏引导的情况下,学生们对软件测试的理解比较片面,他们甚至直接认为软件测试是不重要的。

根据我的了解,很多毕业生在校园招聘的时候,并不会主动选择软件测试岗位;一些同学在得知会被分配到测试部后,十分沮丧,有的还会为此毁约。

虽然也有一些毕业生会主动选择软件测试,但是也并非完全是出于对软件测试的了解,有的是因为性别(比如女性会被告知做软件测试比较合适,因为女性常常被认为不适合从事逻辑性强的编程工作,而且女性给人的感觉比较细心,细心确实是软件测试需要的品质);有的是因为编程能力不强,自觉无法胜任软件开发的职位,于是将软件测试作为“备胎”,先凑合着干。

抱有上述心态的“后备军”进入软件测试行业后,如果缺乏正确的引导,他们就很容易偏离软件测试本身的角色。他们中的一些软件测试工程师可能有很强的编码情节,认为只有写代码才是最有技术含量和最有前途的事情,但目前的测试工作可能不仅不需要编码,甚至连看代码的权限都没有。相比开发,他们会逐渐觉得自己从事的测试工作没有什么技术含量,没有前途。另一些软件测试工程师可能又会走向另外一个极端,将产品质量问题和编码的软件开发人员直接对应起来,总是觉得软件开发人员的水平很差,对软件开发人员抱着一种“哀其不幸、怒其不争”的态度,不能很好地和软件开发人员沟通合作,最后无法真正做好软件测试工作。2. 软件管理决策者对软件测试缺乏正确理解

同时管理着软件开发和软件测试的软件管理决策者,常常会在资源、晋升通道上偏向软件开发,而忽略软件测试。

这是因为,在市场驱动下,软件管理决策者往往会认为软件测试是一种“开销”,而并不是“价值创造者”,有时候软件测试甚至被认为是对产品按时发布有负面影响的障碍,不愿意给测试足够的资源。例如,在产品测试中,开发发布版本延迟,但是测试结束时间并没有顺延,而是压缩测试时间,来保证研发项目进度。

除此之外,很多管理决策者对“软件测试”的理解其实都不够深入,认为测试的价值就是在不断测试中找bug,认为bug发现得越多产品质量就会越好,不理解测试策略、测试设计、测试总结等测试活动对产品的作用和意义。软件测试人员并没有在正确的阶段做正确的事,软件测试人员更多的“价值”(如缺陷预防)无法体现,而是陷入过早测试或者盲目追求软件测试自动化率中,虽然整个项目组看起来很忙,但是效率低下,投入产出比很低。3. “喜忧参半”:软件测试外包

托马斯·弗里德曼有一本著名的书叫《世界是平的》,书中将“外包”作为21世纪“铲平”世界的十大动力之一。外包的好处是显而易见的:站在运营的角度,外包可以让你更加关注核心业务,可以帮助你建立弹性的人力资源构成。

软件测试外包让软件测试“火”了起来。在很多网页上都可以看到软件测试外包公司或者培训机构打出“年薪10万”“进500强企业”等广告,诱惑力十足。

但是“外包”同样也暗示着,对很多公司来说,在公司发展策略上并没有将“软件测试”作为核心、重要的业务去发展。所以我认为软件测试外包对软件测试行业来说是“喜忧参半”。“喜”的是软件测试外包扩大了软件测试队伍;“忧”的是公司在执行软件测试外包或软件测试执行外包策略后,极有可能削弱在软件测试方面的投入,减少对非外包软件测试员工的培训和职业发展方面的考虑。

对软件测试外包员工来说,他们虽然可以在软件外包公司得到较为专业、系统的测试技术方面的培训,但是“外包”行业本身的特点就决定了软件测试外包人员会较为频繁地更换测试产品,对产品实现的理解不会太深入。而对产品测试经验持续的积累、对产品实现不断深入的理解又正是深入软件测试的两大必要条件。加上“外包”行业本身存在着缺乏归属感、缺乏晋升空间等问题,软件测试外包人员就更难在软件测试领域深入发展了。1.2.3 迷茫的软件测试工程师

软件测试工程师在工作中常常扮演着用户的角色,但是大家千万不要一看到“用户”就马上联想到“上帝”,认为软件测试工程师的工作很舒服。在实际工作中,每个产品在发布前都会有很多版本,软件测试工程师在每个版本中都要模拟用户使用的各种场景,遍历用户可能会使用到的各种输入参数,通过系统输出来判断这些操作结果是否能够满足预期。其中很多操作都是重复的,这就需要软件测试工程师有一份“外在”的细致和耐心。

除了“外在美”,软件测试还要求软件测试工程师有“内涵”——懂用户。他们不仅要保证产品满足用户明确提出的功能需求,还需要理解在这些功能背后隐藏的“潜在”需求,如性能、可靠性、易用性、可操作性、可移植性等。可见,要想内外兼修,真正做好做深软件测试,绝对不是一件容易的事情。

软件测试在“入门”上相对软件开发的确要容易些,但是软件测试和软件开发不同的是,软件开发人员只需要理解自己负责的模块就可以胜任工作,而软件测试则需要对整个系统都要有整体的把握,需要站在用户的角度去理解需求,所以软件测试比软件开发更难深入。

但现实是,测试“深入难”的这个特点往往被忽视,“门槛低”却被放大。“门槛低”的另一层意思就是“谁都能做”,技术含量不高。在这种背景下,软件测试工程师在职业发展上自然很难受到重视。

国内某知名软件测试网站《中国软件测试从业人员调查报告》(2011年)中的调查数据指出,2011年软件测试从业人员所在公司中,52%的公司对测试人员的职业规划不明确,26%的公司对测试人员没有职业规划,只有22%的公司对软件测试人员有明确的职业规划。而且纵向对比2010年和2011年的调查数据可发现,这两年的数据并没有明显变化。

对那些工作了两三年的软件测试工程师来说,他们在产品和软件测试技术上都有了基本的认识,足以胜任每天的日常工作后,很自然就会开始寻找新的发展方向和目标。

一个发展方向是软件测试管理。但软件测试的管理职位其实并不多,即使是有独立测试部门的大中型公司,也只会到高级测试经理级别,更别提那些没有独立测试部门的小企业了。所以软件测试工程师在测试管理方面想要有所发展,不仅需要能力,还需要机遇。

软件测试在技术方面又有哪些发展呢?

要想在技术方面有所发展,“深入”是必需的。这本来就不是一件容易的事情,而软件测试技术在“深入”上又比其他领域更难一些,可谓“难上加难”。当软件测试工程师开始进入软件测试职业发展的平台期,变得迷茫、困惑,看不清自己未来的发展方向,需要指引时,又往往找不到方向。我的一位前辈曾经拿“布朗运动”来形容他自己在平台期的感觉,我觉得这个比喻是非常贴切的。正如《奥德赛》中描述的一样,还有什么比徘徊不前更让人感到难受的呢?

职业发展遇到“瓶颈”本来是一件非常正常的事情,但是如果这种情况得不到改善,老是处于平台期的状态,却是“致命”的。在我身边,就有很多从事测试工作3年左右的同事离职或者转岗。《中国软件测试从业人员调查报告》(2011年)也指出,中国软件测试行业有超过七成的从业人员工作年限是0~3年,只有18%的人是3~5年。需要注意的是,这个比值从2009年开始就没有发生过变化。这说明中国软件测试人员在工作经验的分布上并不合理,缺乏持续性。我们在不断“丢失”工作3年左右的、有经验的测试工程师,如果这种情况一直持续下去,很难说中国的软件测试不会“青黄不接”。

所以我想对中国的软件测试来说,引进测试技术,提升产品知识,追求更完美的测试流程,或许都不是最重要的。我们需要讨论“发展”,在软件测试工程师职业发展出现困惑迷茫的时候,可以为他们解惑。1.3 认识软件测试的优势和劣势

我们需要先对软件测试进行一场“再”认识。

从“成熟度”来讲,软件开发行业的整体成熟度更高,人们对软件开发的理解也更为全面深入。正因为这样,人们也更习惯将软件测试和软件开发放在一起比较。虽然软件开发和软件测试都属于产品研发,但是人们的关注点是不同的。软件开发偏向“创造”,而软件测试却偏向“验证”和“确定”,所以软件开发和软件测试对技能要求也是不同的。

人们将软件测试和软件开发放在一起比较的时候,容易陷入“用软件开发的要求来评价软件测试”的思维中,只看到软件测试和软件开发相比的弱势,却看不到软件测试自身的优势。

那么作为软件测试,和软件开发相比,又有哪些优势呢?1.3.1 软件测试的优势

虽然软件测试存在不少困境和迷局,但是这并不能掩盖软件测试自身的优势。

和软件开发相比,软件测试入门相对更容易些。这是软件测试行业的一大特点,其实也是软件测试的优势之一。较低的“门槛”给了软件测试行业和软件测试从业者更多的选择余地。一些企业在招聘软件测试人员的时候,不一定只招聘有计算机、通信相关经验的人,他们可能会根据产品的特点,招聘一些更能理解产品和用户需求的人员,如金融、财会专业的人等,所以软件测试从业者可以是“杂家”,或者说对某些领域来说,“杂家”反而更适合软件测试。从软件开发相对“封闭”的行业特点来说,软件测试就要“开放”多了。另外对想改行从事软件研发工作的人来说,选择“软件测试”作为转型的切入点也是比较合适的。

在软件开发项目中,大多数软件开发工程师都会被分配一个或几个“模块”来编码实现,几个软件开发工程师合作才能完成一项功能是非常普遍的现象。这种割裂式的开发工作模式,让其中的软件开发工程师很难理解产品的全貌,甚至不知道最终用户会如何使用自己的产品。相对来说,软件测试人员是产品研发团队中最理解产品全貌、最理解用户的人,这是由软件测试的工作内容决定的。

软件测试人员不必关心产品究竟是如何编码实现的,不必关心用的是C语言还是C++,不必关心这部分代码是软件开发人员从网上复制下来的还是自己原创的;他们需要关注的是“产品的实现是否和开发承诺要实现的功能是一致的”,这让测试人员自然会去关注“功能”,理解产品的全貌,而不会陷入实现细节。

软件测试人员还会对产品进行“黑盒测试”,这种看似“摸瞎”的系统测试方法,需要站在用户的角度分析用户使用场景,所以软件测试人员必须想办法去全面理解用户,不仅要理解用户明确的需求,还要理解用户“隐形”的需求,如用户的使用习惯、用户行业潜在规则等。所以在产品研发领域,测试人员才是最理解用户的人。

在大多数人的印象中,软件开发整天面对着电脑,两耳不闻窗外事,十指翻飞只为编写程序,是一个很“宅”的职业。你千万不要以为软件测试也是一样的,和软件开发相比,软件测试人员需要有一定的沟通交流能力,这不仅有助于就产品测试中发现的bug和开发人员进行沟通,更重要的是,在很多企业,软件测试人员都会作为产品研发的接口,在用户出现问题的时候和用户进行沟通。除此之外,想要做好测试,协调能力、风险评估能力、数据统计分析能力和报告撰写能力都是必不可少的“软技能”。所以和软件开发要求“深度”不同,软件测试更注重“广度”,要求软件测试人员是“多面手”,有很强的综合能力。

软件测试的这一特点,让软件测试人员可以有更多的职业外延可供选择。换句话说,即使一名软件测试工程师在从事了几年软件测试工作后转行,无论他是改行做销售、客服或其他工作,都可以很快上手,得到认可。这是因为软件测试人员对产品理解,在研发领域可能不够“深入”,但是在非研发领域却做得很好。在广度方面,软件测试人员不会输于其他非研发领域的从业人员;对用户需求的理解,软件测试人员也不会逊色;而沟通协调、分析总结、风险意识等软能力也能帮助软件测试人员很快掌握新领域的知识技能。所以相对来说,软件测试人员其实更能适应这个复杂多变的社会。1.3.2 软件测试的劣势

客观来讲,和软件开发相比,软件测试也存在很多劣势。“入门低”虽然给软件测试行业和软件测试从业人员带来了更多的选择机会,但是也会导致软件测试在软件研发领域的认可度降低,认为软件测试是一项相对简单、没有技术含量(或技术含量低)的工作。这个“印象”直接导致了软件测试当前的困境和迷局。

虽然软件测试的“出口”看起来很广阔,但是和同在软件研发领域的软件开发人员相比,软件测试在软件研发领域的发展却比软件开发人员有限得多,至少这是现状。我们很少看到软件测试人员去做产品研发管理工作,成为开发代表、产品线经理或研发总监;很少看到软件测试人员去做系统架构师(SE)。很多企业,软件测试在管理上的职位,最高就是测试代表或测试经理,在技术上甚至没有职位,没有发展方向。

如果从业者的职业发展目标本就不在产品研发,而只想熟悉产品,那么软件测试无疑是获得这项经验一种很好的实践;但是如果从业者的目标就是软件测试,最后却“被迫”转岗,这样的“宽出口”就不是“优势”,而是当前软件测试的无力之处了。第2章软件测试工程师的职业规划

我的一位同事曾经很认真地问过我一个问题。他说他现在从事软件测试工作已经4年了,但是他不知道现在的工作和自己在工作3年时有什么不同,他想旁观者清,也许我能回答他的问题。此外他还想知道他做软件测试工作到第5年或第6年会怎么样。后来他在工作到第5年的时候转岗了。虽然他已经转岗了,但是最近联系时,他依然问我这个问题,似乎这个问题困惑他很深、很久了。

这件事情对我的触动很大,我相信这个问题是带有一定普遍性的,我也开始系统思考这个问题。

软件测试是一个缺乏发展空间、做到一定阶段后只能通过“转岗”来寻找发展机会的职业吗?

肯定不是。

Martin Pol,欧洲业界公认的“Test Guru”(大佬,精神领袖),1998年欧洲第一届杰出测试贡献奖获得者,并获得英国骑士勋章。Martin在测试领域已经几十年,最后在测试工作上名利双收。而且,据说他的大女儿和小女儿都是做测试的,这是名副其实的“测试世家”。

但是Martin的例子并不能解决“软件测试本身有哪些发展”这个问题。作为“精神领袖”,Martin只能让我们看到最美好的结果,让我们知道这条路是能走通的。有人已经成功了,这给了我们信心和希望。

那么软件测试的职业发展方向有哪些?作为软件测试工程师,又该如何为自己制订职业发展规划?本章将就这两个问题展开讨论。2.1 软件测试的职业发展方向

软件测试在职业发展上,概括说来可以分为“管理”和“技术”两大类。除此之外,软件测试还可以在质量领域发展。2.1.1 软件测试在管理上的发展

软件测试管理是大家比较熟悉的软件测试职业发展路线之一,比较流行的设置包括测试组长、测试经理、测试代表、测试主管、测试总监、测试部长等。不同的公司中相同职位的工作范围可能略有不同,按照管理级别的高低,大致又可分为以下三级。1. 初级软件测试管理者:测试组长

测试组长一般由有两年左右工作经验的测试工程师担当。

由于企业的规模和产品复杂度存在差异,测试组长可能会管理2~5名软件测试工程师。一般来说,测试组长不会负责整个产品,只是负责其中的一个或多个特性。

测试组长并不是完全的管理者。他们从事的管理工作大多仅集中在测试计划的制订和执行上;在产品测试上,他们常会负责产品重点、难点的测试;除此之外,他们还要负责带新员工,让测试工作可以顺利进行下去。2. 中级软件测试管理者:测试经理、测试代表、测试主管

测试经理、测试代表、测试主管排名不分先后,都属于中级软件测试管理者,一般由有4年左右工作经验的测试工程师担当。

中级软件测试管理者负责的对象为产品,可能会管理10~20名软件测试工程师(其中包括测试组长)。

中级软件测试管理者最重要的工作还是运作测试项目,制订并执行测试计划,测试结束后还需要对产品质量进行评估,给出产品发布建议。要做好这些,需要他们掌握更多的项目管理知识,深入理解项目价值,做好项目范围管理、质量管理、成本管理、时间管理、风险管理和人力管理。除此之外,他们还要和开发人员、市场人员、服务人员等密切配合、紧密合作,其间,沟通协调能力必不可少。

他们依然是产品测试的骨干,还是会负责产品测试的重点、难点工作,所以他们也不是纯粹的管理者。3. 高级软件测试管理者:测试总监、测试部长

测试总监、测试部长是软件测试的高级管理者,一般都有10年以上软件测试工作经验,负责的对象是产品线或公司。

高级软件测试管理者需要理解产品的商业目标,直接对产品成功负责。他们需要对测试团队的发展负责,进行人员招聘和培养,留住关键人才,提高或更新不合格人员,提升团队的胜任力和职业能力;负责项目财务管理(预算和控制);负责资源的计划与分配;持续改进测试能力,提升效率和产品质量,从测试的角度对交付产品的成本、周期和质量负责。

我认为,即使是高级软件测试管理者,也不可能是纯粹的管理者。他们依然需要保持对软件测试各种技术的领先性,因为软件测试技术是上述工作能够顺利开展的基础。2.1.2 软件测试在技术上的发展

软件测试在技术上的发展方向,似乎不像软件测试在管理上的发展方向那么明确。一种观点是按照测试资历和能力分为助理软件测试工程师(或者是实习软件测试工程师)、初级软件测试工程师、中级软件测试工程师、高级软件测试工程师和主任软件测试工程师(或是资深软件测试工程师)。但是我认为这种分类方式并没有突出“软件测试技术”,所以我个人更倾向于一种简单的分法——产品测试技术和专项测试技术。

产品测试技术是指把某个具体(或一类)产品测试得更好的技术;专项测试技术并不是针对具体的产品,而是测试领域普遍适用的技术。1. 产品测试专家:软件测试架构师

软件测试在技术上可以向产品测试技术专家方向发展。

有些公司称产品测试技术专家为软件测试系统架构师(本书简称为测试架构师),我认为这个称谓是非常贴切的。

测试架构师和系统架构师在职责上是有一定对应关系的。

系统架构师在业务(需求)向开发技术转换的过程中起到了桥梁作用,负责产品开发的整体架构设计;测试架构师是在业务(需求)向测试技术转换的过程中起桥梁作用,负责产品测试的整体架构设计。

系统架构师负责对产品开发中的技术重点和难点进行研究与攻关;测试架构师负责对产品测试中的测试重点和难点进行研究与攻关,为测试组织提供最优的测试方法。

系统架构师协助开发项目经理制订项目计划和控制项目进度;测试架构师负责协助测试经理制订测试项目计划和控制测试项目进度。

系统架构师负责组织开发项目团队内部的技术培训工作;测试架构师负责组织测试团队内部的技术培训工作。

系统架构师需要有一定的战略规划能力、业务建模能力、数据分析处理能力、面向产品生命周期的质量保证和持续改进能力;测试架构师同样需要这些能力。

有人评价系统架构师是产品开发的“灵魂”,那么测试架构师就是产品测试的“灵魂”。2. 专项测试工程师

软件测试在技术上,还可以向专项测试工程师方向发展,成为软件测试某领域的专家。

从测试体系的角度来看,软件测试发展至今,已经形成了一套完整的测试体系。测试体系中的任何一个环节,测试策略、测试分析设计、测试执行、测试评估、测试流程等每个领域的内涵都很丰富,包含了很多可以深入发展研究的技术,比如自动化测试技术、测试工具(包括产品测试模拟工具和测试流程管理工具)开发、缺陷分析和测试评估技术等。

从产品质量属性的角度来看,专项测试技术还可以包含性能测试技术、可靠性测试技术、安全性测试技术等。

实际上,产品测试专家(软件测试架构师)也需要精通上文提到的各项测试技术,如测试分析和设计、自动化测试技术、性能测试技术。但是,产品测试专家使用的任何技术都是为产品服务的,他需要针对当前测试的特定产品选择最合适的测试技术,并针对不同的产品对测试技术进行适配调整。而专项测试技术专家并不关注具体产品,而是偏向技术共性方面的研究。

表2-1和表2-2概括了一些常见的专项测试技术发展方向,供大家参考。表2-1 测试技术类专项测试技术表2-2 质量属性类专项测试技术2.1.3 “角色”和“段位”

我在做测试绩效辅导的时候,曾经有一个困扰我很深的问题:要想一个测试团队始终保持一个良好的状态,对团队成员的有效激励是必不可少的,但是除了“升职加薪”,我想不出其他的方法。但是我不是老板,“升职加薪”并不是我能把控的(其实即使我是老板,能够做主,也不可能总是用升职或加薪来激励团队)。对一位软件测试工程师来说,他从一位普通的测试工程师新晋升为测试组长的时候,可能会干劲很足。但是一段时间后(或许是一年,或许是半年),他可能又会进入一个新的“平台”。如果此时既没有升职的可能,也没有加薪的机会,我该如何帮助他度过平台期呢?

如果换一个角度想这个问题,其实就是本章开头的那个问题:如果职位没有变化,工作两年的测试工程师和工作3年的测试工程师差别在哪里?工作3年的测试工程师和工作4年的测试工程师差别又在哪里?

直到有一天,当读到了姜汝祥的《请给我结果》这本书中一个关于“秘书九段”的故事后,我突然找到了这个问题的答案。“秘书九段”的故事

总经理要求秘书安排次日上午9点开一个会议。这件事需要通知所有参会人员,秘书自己也要在会议中做服务工作,这是“任务”。但我们想要的结果是什么呢?下面是一段至九段秘书的不同做法。

一段秘书的做法:发通知——用电子邮件或在黑板上发个会议通知,然后准备相关会议用品,并参加会议。

二段秘书的做法:抓落实——发通知之后,再打一通电话与参会的人确认,确保每个人被及时通知到。

三段秘书的做法:重检查——发通知,落实到人后,第二天在会前30分钟提醒与会者参会,确定有没有变动,对临时有急事不能参加会议的人,立即汇报给总经理,保证总经理在会前知悉缺席情况,也给总经理确定缺席的人是否必须参加会议留出时间。

四段秘书的做法:勤准备——发通知,落实到人,会前通知后,去测试可能用到的投影、电脑等工具是否工作正常,并在会议室门上贴上小条“此会议室明天几点到几点有会议”。确认会场安排到哪,桌椅数量是否够用;音响、空调是否正常;白板、笔、纸、本是否充分;自己的准备,在物品上、环境上,可否满足开会的需求。

五段秘书的做法:细准备——发通知,落实到人,会前通知,也测试了设备,还需了解这个会议的性质是什么,议题是什么,议程怎么安排。然后给与会者发与这个议题相关的资料,供他们参考(领导通常都是很健忘的,否则就不会经常对过去一些决定了的事,或者记不清的事争吵)。目的是让参会者有备而来,以便开会时提高效率。

六段秘书的做法:做记录——发通知,落实到人,会前通知,测试了设备,也提供了相关会议资料,还在会议过程中详细做好会议记录(在得到允许的情况下,做一个录音备份)。

七段秘书的做法:发记录——会后整理好会议记录(录音)给总经理,然后请示总经理会议内容没有问题后,是否发给参加会议的人员或者其他人员,要求他们按照会上内容执行。

八段秘书的做法:定责任——将会议上确定的各项任务一对一地落实到相关责任人,然后经当事人确认后,形成书面备忘录,交给总经理与当事人一人一份,以纪要为执行文件,监督、检查执行人的过程结果和最终结果,定期跟踪各项任务的完成情况,并及时汇报总经理。

九段秘书的做法:做流程——把上述过程做成标准化的会议流程,让任何一个秘书都可以根据这个流程复制优秀团队,把会议服务的结果做到九段,形成不依赖于任何人的会议服务体系。

这个关于“秘书九段”的故事给了我很大的启发。测试组长、测试经理、测试架构师、测试总监等,都是被赋予了不同责任的“角色”,“角色”的转变可以在一定程度上反映职业的发展,但是不能说“发展”一定要“角色”发生变化。从“秘书”变成了“老板”,是“发展”没错,同样从“一段秘书”升级为“二段秘书”也是“发展”。

所以虽然我控制不了升职和加薪,但我可以通过“提升段位”来激励团队成员。这是我可以做到的。

反过来,每个测试人员,是不是都该自问一下,在当前的测试工作中,自己属于哪一段,以及如何才能进入下一段?

我和我的同事曾经讨论出了一个普通测试工程师的“测试六段”,这不是一个所谓的“标准答案”,仅供大家参考:

测试一段:能根据测试用例的描述步骤来执行测试用例,能对照用例的预期结果发现产品的问题,能够清晰准确地将问题记录下来后反馈给开发,开发能够读懂问题描述的含义;

测试二段:对产品需求有一定的了解,能够根据产品需求分析、设计产品的测试用例,发现问题后能够进行初步定位;

测试三段:对产品的需求和实现都有较为深入的理解,设计用例时会注意用例的有效性,测试用例时会考虑使用自动化测试等方法提升测试执行的效率;

测试四段:深入理解产品需求和实现,理解产品质量,理解产品的隐形需求,对产品性能、可靠性、易用性等非功能属性的测试均有所涉及,并掌握其中的测试方法,会使用测试缺陷分析技术,会评估产品质量;

测试五段:不断追求最适合产品的测试技术,关注测试过程改进,推动产品测试技术的进步;

测试六段:走向前端,做缺陷预防,能将测试方法标准化,并固化为测试工具和流程。

读到此处的朋友,请你不妨也为自己量身定制一个“测试段位”,并在测试的职业生涯中不断地修正、丰富它。相信这个“段位”,会在测试职业发展中给你带来意想不到的帮助。2.1.4 软件测试在质量领域的发展

软件测试还可以向“质量管理”领域发展。

很多人可能会认为“软件测试”和“质量管理”是可以画等号的。我们在讨论软件测试发展简史时,提到的软件测试理念,无论是“证实”还是“证伪”,其实都是为了“验证软件是否能够满足用户的需求”。而“质量”是什么?Crosby认为“质量就是满足需求”,从这个角度来看,“质量”和“测试”在内部确实有很强的关联。除此之外,测试理念中的“缺陷预防”和质量管理的思想也是一致的。所以称“软件测试”是一种“质量”活动,是没有问题的。

但是,我们不能因此就认为“质量”活动就是“软件测试”。“质量”并不是软件领域独有的,早在工业革命时期,“质量”就开始发展了。当时的质量叫“质量检验”(QI),就是关注“产品能否符合工厂制定的标准”。随着社会生产力的发展,产品生产环境、生产能力的提升,质量也有了新的定义。“质量控制”(QC)的提出,标志着开始从用户的角度来评价质量。在ISO9000(1986,1994)中,又进一步发展为“质量控制(QA)”,“质量是设计出来的”“质量就是满足用户的需求”“客户满意度”成为新的质量发展方向。现在,质量进一步发展为“卓越运营”,质量已经被提到了企业战略的角度,“质量管理”也成了现代企业管理中非常重要的一个环节。

从上面这段论述中可以看出,“质量”是贯穿产品全过程的大质量,而软件测试关注的是“产品质量”的小质量。对企业而言,“产品质量”只是质量管理中的一个方面,除此之外,质量管理还需要关注“交付质量”和“经营质量”,最终目标是要达到“卓越运营”。

既然软件测试可以认为是质量领域的一个子集,软件测试自然也适合在质量领域发展。主要参考方向如下:1. 产品流程设计

负责企业在产品开发、市场、交付等全流程体系建设。例如,著名的集成产品开发(Integrated Product Develop,IPD)流程。2. 企业质量管理者

企业质量管理已经成为企业管理的一个重要组成部分。

质量大师朱兰把“质量策划”“质量控制”和“质量改进”称为质量管理三部曲。每一个步骤的具体含义如下:

质量策划:致力于制订质量目标并规定必要的运行过程和相关的资源以实现质量目标;

质量控制:致力于满足质量要求;

质量改进:致力于增强满足质量要求的能力。

企业质量管理者通过这三部曲系统地对企业的质量进行管理。质量管理体系方法可以概括如下:

· 建立一个以过程方法为主体的质量管理体系;

· 明确体系内各过程的相互依赖关系,使其相互协调;

· 控制并协调质量管理体系各过程的运行,关注其中的关键过程,规定关键活动的运作方法和模式;

· 理解为实现共同目标所必需的作用和责任,减少因为职责不明导致的障碍;

· 在行动前确定所需资源的需求;

· 设定系统目标以及各个过程的分目标,通过分目标的实现,确保实现预期的总目标;

· 通过监控和评估,持续改进质量管理体系,不断提高组织的业绩。

当然,这里的质量是我们前面提到的“大质量”的概念,不仅仅是指产品质量,要达到的效果是企业整体质量的提升。3. 客户满意度管理专家“客户满意”是产品成功的关键因素,没有之一。关注客户的声音,让客户满意,无疑对产品质量提升有非常重要的意义,“客户满意度管理”也受到越来越多的关注,成为质量管理的一个重要内容。

对“客户满意度管理”来说,重点是要识别关键用户的满意要素和做好与用户接触点相关的质量保证。“关键用户满意度要素”是指通过对特定细分市场进行市场调查后,分析得出这类客户对特定的产品质量要求和服务属性,并把关键客户满意度要素作为企业产品与服务战略的输入,使企业最大限度地保持产品竞争力;而“用户接触点相关的质量保证”是指包含客户可以感知到的产品和服务,其中服务包括产品推广、投标达标、供货保障、工程交付、技术支持、备件支持和客户培训等。客户对任何接触点都会产生好或者不好的感知,所以需要定义各接触点的关键、标准动作,并确保执行到位,提升客户感知质量。

客户满意度管理,前提还是需要对用户有很好的需求和理解。和软件测试不同的是,这里的客户需求,已经不仅仅局限于产品,而是客户可感知的方方面面,涉及面会更广。对于软件测试工程师来说,往客户满意度管理方面发展,也是不错的选择。2.2 软件测试工程师职业规划建议

上一节讨论了软件测试工程师有哪些可供参考的职业发展方向。本节主要针对软件测试在制订职业规划时可能会遇到的一些问题,提出个人的处理建议,供大家参考。2.2.1 做管理还是做技术

软件测试在职业发展上可以概括为“管理”和“技术”两大类,这点大家已经比较明确了。现在的问题是,该走管理路线,还是该走技术路线呢?

也许是受到中国传统思想观念“学而优则仕”的影响,面对这个问题,很多人会不假思索地选择做管理,甚至会认为一个30岁的软件测试工程师还在做技术是一件丢人的事情。其实我们可以先抛开其他问题不谈,单纯从时间上来推断,本科生正常情况下23岁毕业,到30岁有7年的时间;研究生25岁毕业,到30岁只有5年的时间,对软件测试这种深入难、且对从业者综合要求很高的职业来说,5年、7年其实并不算太长,对软件测试的理解,只能算是“管中窥豹”而已。所以我建议软件测试工程师在计划职业发展里程碑时,可以把时间放得更长一些,5年一个小台阶,10年一个大台阶,也许对软件测试行业来说,更合适一些。

另外,软件测试在“技术方向”和“管理方向”上又是可以相互转换、交叉发展的,测试管理者可以转岗为测试架构师,测试架构师也可以转岗为测试管理者。图2-1是这种转换关系的示意图。图2-1 软件测试在“管理方向”和“技术方向”上的相互转换

为什么软件测试具有这样的特性呢?这是因为软件测试是一门基于实践的学科,对软件测试来说,“管理”不可能是“绝对的管理”,软件测试的管理者首先要是产品测试技术专家,这是“做正确的事”的基础,很难想象一个不懂测试技术、不理解各项测试活动的软件测试管理者如何评估软件测试的重点、难点,如何做计划,如何评估风险控制项目进度;与此同时,“技术”也不能是“绝对的技术”,不理解“价值”“目标”和“成本”的技术人员容易犯的错误就是陷入“唯技术论”中,缺乏“管理”思想会让他们制定的测试策略不切实际,一纸空文的测试策略是没有意义的。

一个理想的测试团队,具有测试经理(测试代表)和测试架构师两个角色。测试经理负责管理,测试架构师负责技术,但并不意味着测试经理只管管理,只懂管理,测试架构师只管技术,只懂技术。相反,测试经理(测试代表)和测试架构师要熟悉彼此领域的关键活动,能够评审关键的交付件,相互能够提供各自领域关键活动的决策参考,可以相互备份。测试经理和测试架构师之间有分工,更多的是合作。

所以,我建议测试管理者一定不要过早地放弃技术,走所谓的“纯管理”路线,把自己陷入各种管理会议、沟通协调中。不要认为读了几本书,参加了几个沙龙论坛、几次培训就能掌握关键的测试技术方法,只有在产品测试中不断地实践、总结、再实践、再总结,才能不断地提升自己。如果测试技术有短板,测试管理水平也不可能真正上去,随着测试资历的加深,职业能力和资历会变得越来越不匹配,个人的职业发展道路反而会越来越窄。

对测试架构师来说,除了产品测试技术外,还需要更深入地理解产品的价值,要围绕如何让产品成功去做测试策略,学会取舍,而不能只站在测试技术的角度去做策略。只有产品成功了,产品测试才有资格去谈是否成功。失败的产品,测试得再好,又有什么用呢?2.2.2 对测试工作“跳槽”的建议

在“跳槽”这个问题上,对软件测试,我有以下几点建议。

第一,不要轻易跳槽,学会“韬光养晦”。

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载