对软件测试岗位价值的理解_对软件测试岗位理解 - CSDN
  • 软件测试人员的价值

    千次阅读 2017-01-20 11:38:54
    最近公司一直在提“软件测试人员的价值到是什么”,测试的价值应该体现在哪里呢?  在网上看到一本书中的一句话“软件测试的真正价值并不体现在代码中找出了多少缺陷,而是发现设计和编程人员解决问题方法上的局限...

       最近公司一直在提“软件测试人员的价值到是什么”测试的价值应该体现在哪里呢

       在网上看到一本书中的一句话“软件测试的真正价值并不体现在代码中找出了多少缺陷,而是发现设计和编程人员解决问题方法上的局限,思路中的狭隘和技能方面的不足”,个人觉得有写道理,分享一下。

       下面是看到的一段话,也分享一下:

      常常,在面试时我会问应聘者:“做测试工作,让你感到自豪的事是什么?”,大部分人回答的是:“发现Bug,特别是一些让开发难于解决的严重bug,是最开心,最有成就感的事了“。而相反,测试大师们恰恰建议我们要丢弃软件缺陷数量、缺陷严重性、测试用例的多少、自动化代码量等可量化的衡量指标,转而通过观察测试人员提高了多少开发人员的工作绩效来评估。

     就测试而言,质量如生命,效率如健康。软件测试人员是质量的最后把关者。谈到质量,我们会提及很多方法,如黑盒,白盒,灰盒,最近比较流行的敏捷测试,探索性测试等。谈到效率,我们会不由自主提及自动化测试,自动化工具等。测试的使命就是围绕产品的质量、效率转。我们的出发点都很好,但在解决问题的方法上,往往是集中在结果上,即出现了什么结果,再去想办法解决它。对于测试来说,可以理解这个“结果”就是软件的缺陷。我们经常也谈,测试要尽早介入,尽早发现问题,尽早把bug消灭在摇蓝中等。这些说的都是事,而我们恰恰忽视了一个很最重要的东西,就是在整个产品开发链中,产生这些事的人的问题。(注:这里不是谈人的管理问题)。如果我们能盯住人(角色),因为这些问题实际都是由前面的人产生的,我们是否可更加轻松。

      把我们的眼光放得更宽远一些,锁定可能会出现问题的设计人员或编程人员身上,用心去发现他们解决问题时的方法局限,思路狭隘或技能不足的体现,便能尽早发现问题。

     

        

    展开全文
  • 之前曾写过《软件质量管理的困境与对策思考》,在其中谈到开发部门与质量管理部门(QA)应形成一个有“交集的双环...通常,软件开发团队似乎几乎不谈论自己的“核心价值”,而针对测试团队总有该问题的特有思考是...

    之前曾写过《软件质量管理的困境与对策思考》,在其中谈到开发部门与质量管理部门(QA)应形成一个有“交集的双环”而非“哑铃型”组织,也指出软件质量管理应重实践轻量化,其目标应是帮助工程师改善工作习惯和提升开发环境的效率。那时并没有认真地思考过测试团队的核心价值,直到读到@段念-段文韬老师的《测试团队与咖啡店》。


    通常,软件开发团队似乎几乎不谈论自己的“核心价值”,而针对测试团队总有对该问题的特有思考是不是折射出了现实的一些状况?因为但凡探寻“核心价值”时,往往意味着价值不够清晰或者找不准重点。


    以我过去一直从事软件开发相关工作的经历来看,测试团队对于“核心价值”的特有思考的确存在其必然性。探讨其根源让我们从一个“游戏”开始。


    “零和游戏”之困

    多数软件企业都设立了开发与测试两个部门,且两个部门属于企业价值链中的两个有交互但又独立的节点。在企业中只要是个部门就大多存在绩效考核问题,似乎只有这样才能证明该部门存在的必要性。


    软件测试部门的角色通常定位为“质量卫士”。自然地,他们所发现软件缺陷的数量和严重程度与其绩效潜移默化地有着紧密关联。于是乎,测试工程师为了体现其价值,希望尽可能在缺陷跟踪系统中新建缺陷记录。但开发工程师就不干了,因为缺陷数量同样可以作为考核指标以衡量其开发质量。进一步我们有了这样的工作场景:测试工程师发现问题后,首先与开发工程师进行沟通,在征得开发工程师的同意后再新建缺陷记录(这个过程有时变成了一种博弈,而非真正为了工作效率);开发工程师对于测试工程师所发现的问题不是持感激态度,反而认为他们是在“找麻烦”。由于“质量卫士”的存在,开发工程师心安理得、堂而皇之地认为保证软件质量是测试部门的事。


    不难发现,这样的体制下其实创造了一个“零和游戏”。这个游戏给我们带来的困境是:测试部门的“赢”(发现了更多的缺陷)意味着开发部门的“输”(开发质量不佳);反之亦然。总而言之,两个部门很难达成共赢,有时甚至出现各自为政的极端状况。


    软件质量的概念

    估计没有人会质疑测试活动本身的价值,其背后的道理恐怕再简单不过了。但我们仍需先探讨一下什么是软件质量(后面简称为“质量”),不明晰这一概念会很难保证测试活动能有的放矢。


    我在《专业嵌入式软件开发》一书中曾指出,质量是分级的,它包含用户和团队两个级别。简单说来,用户级的质量由软件缺陷去反映,而团队级的质量反映于开发团队能否按步就班地实施开发工作而非经常处于“救火”的“紧急状态”,团队级的质量是涵盖用户级的更高形式。我在该书中还指出,软件设计是质量之本,只有高质的软件设计才能保证团队级的质量,并最终长期给我们带来用户级的质量。这些主张很明确地表示,质量首先由软件开发工程师负责。


    用户级的软件质量我们可以通过根据需求文档编写的测试用例来加以评估。但是团队级质量(即软件设计质量)则很难通过这些测试用例去评估,但软件缺陷数量却也能反映出一定的情况。如果某项目的软件缺陷数量在相当长的时间内出现幅度较大的波动,这大多意味着软件设计存在问题,也表明开发团队并没有从根源上解决问题,而是采取了“七修八补”的短期行为。另外,从开发团队是否时常处于“救火”状态也能很大程度地反映出软件的团队级质量水准。


    我们需要测试工程师吗?

    理想情况下,测试可以由开发工程师们去完成,因为“他们知道软件的所有实现细节”,但现实与理想总是存在差距。完全由开发工程师去完成测试工作存在以下可操作性问题:

    1)对开发工程师的能力要求太高。这些家伙不仅要精通编程语言、熟悉业务,为了测试还得掌握测试理论、测试方法和实施测试所需的脚本语言。要求一旦太高,就容易出现资源稀缺的现象。另外,我们设想一下,工程师如何才能达到这么高的要求?学校里学?还是工作中学?如果在工作中学,那么在没有达到要求前他们在工作中承担的角色又是什么?

    2)当开发时间很紧的情形下,要让开发工程师同时关注设计质量和测试质量几乎不大可能。现实中,能顾及前者就算是很出色的开发工程师了。此外,这种不可能不是单方面由开发工程师决定的,而是有太多的项目管理团队总有“压缩时间能促使开发团队不散漫”的错误认识,而没有意识这种认识驱使的行为所带来的副作用——影响了软件的设计质量。

    3)开发工程师们通过采用软件模块化的方式实现协作,这种情形下一定需要有人从测试的角度去统领整个系统,靠开发工程师自己实在勉为其难。


    面对这些可操作性问题,如果有人还一味地坚持测试工作应完全由开发工程师完成,那只能说他在否认社会分工的益处,也很可能是忘记了自己在成长为“全能选手”前所承担的角色。


    综上所述,我们需要有测试工程师与开发工程师共同努力以实现质量目标,而这也意味着测试工程师是有价值的!


    测试工程师贡献价值的方向

    测试工程师要很好地贡献价值,首先要与开发工程师有共同的目标。也就是说,开发与测试团队先要把质量目标变成“我们的”,而不是“你的”或“我的”,否则很难打破“零和游戏”所带来的困境。就这一点,我完全认同@吴穹老师在他的《测试的双重目的性及理性质量观》一文中所倡导的“只有将开发和测试完全地混合在一起,不分彼此,才能够真正获得好的质量,不应试图去隔绝开发与测试团队”。换句话说,开发与测试团队在组织架构上的关系要做适当的修正以支撑这种主张,否则它是阻碍测试团队输出价值的第一个巨大障碍。


    所制定的共同质量目标最好是团队级别的,因为从开发工程师的角度来看,只有这样才能保证开发工作按步就班,也意味着他们和公司能从中获得最大的收益。从这个角度说来,测试工程师可以考虑“我如何帮助改善软件的设计质量”。这个问题或许太大,对测试工程师的要求也太高(后面我们还会谈这方面的内容),但我们可以从“如何保证软件的可测试性”这种更具有指导性的问题入手。


    退而求其次的是,测试团队与开发团队共享相同的用户级质量目标。在这个层面上,测试团队将发现巨大的发挥空间。比如,测试团队能否搭建或改善单元测试的平台,以帮助开发工程师更方便地实施单元测试;又或者能否帮助开发工程师构建持续集成的平台;等等。


    请注意,我并非主张测试团队应对开发团队言听计从,而是主张测试团队应使用自己的测试专业知识帮助开发团队提高开发质量与效率,而非只充当检验员的角色。测试工程师一定需要建立团队的自信:测试是一个专业领域,在质量保证方面我们有自己独到的见解,能为开发工程师提供帮助。


    总的说来,测试团队需要站在测试专业领域的高度为开发团队提供指导与帮助,也只有这样开发工程师才能感受到“我们拥有同一个质量目标”。这种观念我想也正是@段念-段文韬老师在《测试团队与咖啡店》一文中想强调的。另外,Google让测试团队隶属于Engineering Productivity这一FA(Focus Area)或许也正是出于这一考虑的吧!


    现实的无奈

    读者可以从网上搜索《Google是如何做测试的》这个系列翻译文章,其中谈到了Google是如何组织测试的,里面的内容很值得我们学习与思考。总体说来,我觉得Google对于测试工程师和测试开发工程师的要求相比国内我所见到的更高,且其中开发测试工程师的作用非常关键,他们review设计、审查代码的质量与风险、重构代码使之具备更好的可测试性、编写单元测试和自动化测试框架等。


    回头看看国内,好象将测试当作比开发次要而非同级。对测试工程师的要求似乎也没有开发工程师高,这一点从招聘时碰到某位工程师不适合开发岗位时会考虑他是否适合做测试可以看出。以我的理解,测试工程师应当是开发工程师出身且水平更高,因为只有水平高了才能对软件质量有更深刻的认识,才有能力从质量层面贴心地指导和帮助开发工程师的日常工作。


    测试团队对“核心价值”困惑的存在,很大程度上是由于国内对测试的重视不足,强行割裂开发与测试两个活动而导致的。其所带来的更大危害在于,测试人才缺乏一定的梯度。


    展开全文
  • 在开始这篇文章之前,先问问自己,在软件测试这个行业,你的核心竞争力是什么?你有想过这个问题吗?若想过,你的答案是什么?有想明白吗?或者,你还在迷茫?在茹炳晟的极客时间专栏《软件测试52讲》有这样一个问题...

    借这篇文章,我们来谈谈功能测试、测试开发、性能测试工程师等的核心竞争力。

    在开始这篇文章之前,先问问自己,在软件测试这个行业,你的核心竞争力是什么?你有想过这个问题吗?若想过,你的答案是什么?有想明白吗?

    或者,你还在迷茫?

    在茹炳晟的极客时间专栏《软件测试52讲》有这样一个问题:“在日常工作中,我们很少会听到开发工程师谈论自己的核心竞争力,往往都是测试工程师更关注这个问题。这是不是从某个侧面反映出测试工程师的核心竞争力不够清晰或者是随着互联网时代的到来而发生了很大变化?”

    有用户留言说:“开发很少讨论核心竞争力,是因为开发的学习路线和发展路线比较清晰,而测试,大家都是在迷茫中摸着石头过河。”

    也有用户说:“如果是开发转测试,去做测试开发,可能更清楚自己的路线和规划;但如果从功能测试入门,很容易迷茫,因为入门很容易。”

    以下内容来自于2018年11月23日晚19:30的直播整理。嘉宾是有着16年测试经验的茹炳晟,前eBay中国研发中心测试基础架构技术主管,极客时间《软件测试52讲》专栏作者。

    \"\"

    功能测试、测试开发、性能测试工程师等核心竞争力

    茹炳晟:这是一个非常典型的问题,因为现在我们看到一个很基础的现象:

    • 功能测试工程师想去做自动化测试,他觉得写自动化测试是价值,他能从中学到新的内容;
    • 自动化测试工程师想干吗呢?他觉得我自动化能力已经掌握了,我想更多地了解一些业务,了解这个产品的使用知识。

    其实,他们都在追求自己所当前的一个角色下所没有的能力与内容。

    这是好事,也是坏事,为什么?

    作为一个工程师,你想清楚自己是在哪个阶段上,你想往另一个方面去发展的话,那么你一定需要在另一个方面去做额外的努力。那么这个做努力的过程中,从知识积累的角度来讲,它一定是从深度再到广度。

    那这个深度怎么来?那就是在你所有深耕的领域里,你应该去发挥你专家的作用。那么我们回到三类工程师,测试开发工程师,业务的功能测试工程师,以及性能测试工程师。

    1、功能测试工程师。非常简单,他的核心价值是对产品的理解,对需求的理解,对产品使用的理解,以及在这些产品实现背后的一些实现逻辑。但,这类工程师本质上是有个短板的,这个短板来自于他的知识面会被局限。也就是说,你在这个领域,你是有价值的,但是一旦你离开了这个领域,你怎么能够把你这些专业知识能够很好得带出去,这其实是值得这类工程师深思的一个问题;

    2、对于第二类工程师,我们称之为测试开发。测试开发工程师是现在非常热门的一个职业,可以说,所有的测试工程师基本上都想往那个方面去发展。为什么?因为在这个时代,你说一个工程师,一个软件方面的工程师,一个工程技术人员,如果他没有掌握开发的技能,没有代码的技能,他不能称之为一个优秀的工程师。那么在这种情况下,我们会去想测试开发的价值,无论从工程效能的角度来讲也好,还是从具体的这种工具链上,测试开发的确带来了很多帮助。有人说,这个职业工资高。工资高,说明企业愿意出这个工资给你,一定是认可你能够带来更高的价值。

    做测试开发也会遇到一个很现实的问题,如果你想做测试开发,你第一个要解决的是你的开发技能,因为有很多半路出家或者非计算机专业的,信息类专业的,他对计算机领域的知识,或者说一些基本的编程语言知识是相对薄弱的,那么在这种情况下,他要去转成测试开发的话,他需要很大的开发工作积累。而且开发工作的积累,单靠你一些语言的学习并不能真解决很核心的问题。为什么这么说?因为你学的是书本上的东西,而真正的开发,一定来自于那些工程实践,你只有做过真正的工程实践,你对这个语言的理解,你心里才是有底气的。

    那么更进一步的来讲,我想问大家一个问题,测试开发工程师到底是测试重要还是开发重要?如果有两个优秀的候选人A、B都去面试测试开发的岗位,A是测试的背景很强,开发相对薄弱,那B是开发相对很强,但是测试薄弱,那你怎么来选人?

    站在我个人的角度来讲,或者站在我个人的经验来讲,我是觉得测试要比开发来的重要,为什么?因为从整个行业来讲,你不缺的永远是优秀的开发人员。但是能够站在测试的角度,能够提炼测试的需求,并且把测试当中的一些难点,或者一些能够提高工程效能的点进行提炼,并把它做成工具,这种测试人才是很稀缺的。

    我在我的《软件测试52讲》专栏里提到过很多方法,像我们做的Test  Data  Service、测试服务、测试执行服务,这些东西本质上并不是很难,它比业务系统的开发来的简单,而且它的可用性,包括它各种各样的要求也都要比传统的市场上面向终端用户的要求来的低。但是这类软件的核心价值就在于你能想到去做这个事情,并且能很准确地打到这个点,并把这件事情做出来。完整作出这件事情,会很大程度上去提高你的开发、测试以及整个DevOps整个生命周期。这种情况下,这类人的核心价值应该更多的是在测试,开发只是辅助的,所以说测试开发工程师的核心价值,是对测试的生态的理解,以及对工具需求的提炼,以及把这些提炼出来的需求以最简单的方式最容易落地的方式来做实现。

    第三类,性能测试工程师。我为什么只讲性能不讲安全?因为性能和安全是从一个能力的核心竞争力来讲,他们很像,他们属于专才。这类人的知识是需要经过很长时间才能积累起来,而不是一蹴而就,也不是通过一个简单培训就能够把这类人培养起来。这种人,他看到的业务场景越多,看到过的问题越多,他能很快地根据这个问题的现象,去决定进一步做怎么样的测试,或者去拿哪些指标。有了这些指标之后,他可以快速缩小问题的范围。

    这种能力来自于哪里?这种能力很大一部分都来自于实践工作经验,你在工作经验中看到过这个问题,你才能去解决这个问题,你才会这方面会有想法。性能测试工程师就像医生,他去给病人看病的时候,医生会让病人去验血,会拿到一个验血报告,验血报告上面说有大量不同血液的指标,但是一个血液指标拿到很容易吗?现代化的仪器就能帮你拿到了,那么性能测试指标能拿到吗?也非常简单,监控工具可以帮你拿到各种各样的监控数据,这是很容易帮你拿到的,但是拿到的这些数据意味着什么?你能通过这些数据里面,看出什么问题来吗?

    有经验的人通过这些数据看到左右问题的本质,或者是这个问题的方向,进一步应该往哪个方向去看这个问题,但是没有经验的人,这对数据来讲,就是一堆数据,它不能解决问题,所以说测试工程师,性能测试工程师,很大一部分来自于经验的积累,一定是通过很长时间的去培养,总结出来的。

    \"\"

    为什么会讲到“软件测试开发者的核心竞争力”

    茹炳晟:这是个非常有意思的话题,就像我们经常说的“团队中的价值问题”,你经常看到测试人员自己在想,我们的价值在哪里、是什么?但我们很少看到软件的开发人员或者架构师,或者运维团队去问这样一个问题,要去找自己的价值。这是因为测试人员对这个价值本身是不太确定的,那么这个价值本身不确定,就会带来的一系列的问题。

    你在整个快速发展的互联网时代,整个IT的发展时代里,你如何定位自己?你怎么样能够成为一个优秀的工程师?怎么样成为一个不被时代所淘汰的,并且能够紧跟时代步伐的这样一个工程师?这样的一个工程师你的核心竞争力又在哪里?

    记得刚一开始从事软件的时候,有些大学的本科,或者研究生毕业,他们去面试工作的时候就会发现,面试下来的是代码能力可能不是太好,这种情况下公司会问你愿不愿意去做测试?但随着现在这个时代的变革,现在的软件测试工程师,他的知识面,以及他需要掌握的内容已经远远超过了之前,可以说他的知识面是远远超过开发的,比如在一些技术的面上,以及对产品的理解上。

    那么这种情况下,我们再去提一个优秀的软件测试工程师的核心价值,我们可以很自信地说,测试工程师是一个不可被替代的,并且是一个专业细分化的领域。像早年的时候,我们谈到测试,就是软件测试,没有细分市场,但现在你去谈测试,测试现在的领域太多了,除了传统意义上的,基于业务领域的测试,然后还有测试开发。

    测试开发里面又分为两个大的分类:

    1. 一类是专门做测试基础架构,做平台,做工具开发的;
    2. 还有一类是专门去这些平台去做测试用例的,自动化测试用例开发的。

    这种情况下,又是两类不同的工程师,那么他所Deliver的价值也是完全同的,那么更进一步,我们还会看到有很多所谓的安全测试工程师、性能测试工程师,这一类都是一些垂直领域的。在每个垂直领域上,大家都有自己非常专业的领域,而且有非常专业精神的知识,尤其是对于像那种性能测试工程师,他知识面的积累不管从广度,还是从深度来讲,都需要很强的系统架构师层面的支持,他才能够成为一个比较优秀的工程师。

    当时在专栏里写《软件测试工程师的核心竞争力是什么?》这篇文章,我就是想让大家走出迷茫期。因为我相信,很多测试人是很迷茫的。因为在整个IT行业的快速发展下,会出现很多的中小型企业,这些中小型企业处在一个快速去堆功能的阶段,他对于软件的测试及对软件的质量本身,并不会有太多的投入。刚开始,他是想把整个功能堆起来,在这种团队里面会有测试,但测试的地位,或者他所扮演的角色、价值通常不会很高,因为他通常是从功能做出来的,在后面去把这个东西快速地测一把。那么这种角色多了之后,或者做了大量重复工作之后,他会对自己的职业发展产生很大的迷茫,不清楚我所做的这些重复性的劳动的意义何在?以及我的价值,我的将来在哪?

    我想通过这样一篇文章告诉大家,测试领域有很多东西是值得的做,如果你觉得重复做事情,非常烦琐,那其实就是你的一个机会。也就是说,有很多东西都不称心,比如工具不称手,流程不称手,或者说你的工作大量重复,那就意味着,从测试的角度,从自动化的角度,从工具的优化,从测试基础架构的建设,你有很多东西可以去做。

    去考虑把你身边天天碰到的这些重复性劳动,用一个简单的脚本,或者做一个简单的工具去做优化,这就是你的一些价值。这种价值,一方面是来源于你对整个知识体系的理解,你的想法,你的思想方式,以及你的行动。那么在这个过程中,你就体现了你作为一个测试人员的价值。随着你做的这种工具越来越多,随着你做的知识面越来越广后,你会发现,你能做的事情就会更多。

    当你很肯定,很自信地确认自己所做的东西是有很大的应用场景的,解决很多问题的时候,你不会再回过头去想,我今天所做的工作的Value在哪里?我的价值在哪里?

    当测试人想往高处走时,是追求测试的深度,还是测试广度?

    这也是一个非常好的问题。
    因为早年的时候,我们学习新的技术,或者我们学习一些新的方法,学习资料的资源是比较有限的,我们只能认准一本书,认准一个学习资料慢慢去啃。但现在,整个互联网的技术发展突飞猛进,一天一个样,发展的速度真的实在是太快了,而且信息本身的体量,数据量都是成指数级的爆炸,在这种情况下,测试工程师就会比较迷茫,到底是把一件事情做精了,还是应该更广泛地去掌握更多的知识。就像现在的测试工程师,如果你不懂系统的架构知识,如果你不懂容器知识,你是很难成为一个优秀的互联网时代测试工程师。

    那你是怎么去做权衡、去做取舍?因为大家的时间、精力总是有限的。从我个人的经历来讲,一定是从深度再到广度。

    我所讲的“深度入手”并不是说,你一定要把某一个点做得非常深,而是不要轻易放过!你在工作当中,如果接触到了一个技术,或者接触到了一种架构设计,或者接触到了一些算法,你千万不要把它轻易放过,你不是得过且过,我测了就测了,我知道了就知道了,你一定要刨根问底。比如说你碰到一个缓存问题,不是说解决这个缓存问题就OK了,你测试完就OK了,你需要把这个缓冲问题的来龙去脉,以及它的发展,以及整个缓存的基本原理,都搞清楚。

    碰到一个击破一个,碰到一个击破一个。

    如果你能坚持以这种方式来对待技术本身的话,你很快会发现,你每个接触过的技术都会变得比较深入。随着你的项目接触的越来越多,做到的事情越来越多之后,你很快就会发现,你有了深度的同时你就有了广度。

    对于广度我也有一些建议,我在我的测试专栏里有一篇文章,“作为一个测试工程师,我们尽可能应该去掌握的知识点有哪些?”。比如说如果你没有互相网基础架构的知识,你想做测试是很难的,或者说你不知道自己不知道,那么会让自己陷入一个很被动的局面。

    对于这种软件,我还提到了,我们还应该去学容器、云这类知识。你要刻意去做这种广度上的学习,因为这类知识在整个体系下已经用的越来越多了,你所在的开发环境,你已经逃不过Docker了,已经逃不过容器了,你所有的应用都在云端了,你怎么样通过云端,你如果对AWS不熟悉,对PCF不熟悉,你怎么样来去部署你的测试环境?怎么样来部署你的开发环境?怎么样将你的测试执行环境,测试基础架构建在云端?

    我个人的建议是通过一些额外的方式,通过自学习的手段,去做一些有意的积累。极客时间就提供了这样一个很好的平台,对于一些热门的技术都有特定的专栏。虽然我是极客时间专栏的作者,但我自己也订阅了很多极客时间的课程,因为有文字且配有音频,就可以利用很多碎片化的时间来学习。比如说我坐地铁的时候,我就会用这段时间来听一个5分钟到15分钟的音频,比你刷微博、朋友圈收获的更多。

    测试想去转测试开发,他需要积累哪些经验?

    一个普通的测试人员,可能更多想转型为测试开发工程师。那需要什么知识点呐?

    我觉得技术的路是没有捷径可以走的,如果你想转成测试开发,那就意味着你要有开发的基础,这种情况下,你做得第一件事情是掌握一门语言。不要多,只掌握一门语言就行。这意味着你是真正地掌握,从骨子里掌握这门语言,而不是简单写个Hello  World。而是你要掌握编程语言很核心的东西,并且你能够通过编程来做一些实际的项目。

    从个人发展角度来讲,我更倾向于学Java。因为Java的面更广,Python虽然好,它更多的还是在测试领域里面。当你一旦跳出这个测试圈子,你想做更多的事情,Java语言还是会来的更好。这是我的一个建议,从开发的基础职能入手,去实践去编程。专栏告诉你的是一个方向,是一些思想方法,以及整个生态,以及工具体系的分析,而不是我手把手教你一个工具。手把手教你一个工具是没有价值的,因为学一个工具最好的路径去看官方文档,官方文档一定是最新的,而且最全面的。

    测试用例的力度怎么去把控?

    我们如果要把这个问题谈清楚,就要看它是一个GUI的测试,还是一个API的测试。不同的测试用例的力度把控差别是非常大的,而且产品的不同阶段、不同规模,还有项目的性质,对于测试力度的把控也是会有巨大差别。

    举个简单例子,如果是一个长期的产品,自动化会进行长期维护的,那么一定要做可复用很高的力度,并且这些可复用的脚本可以被尽可能的多测试用例去使用。但如果是一次性的项目,或者能够短期项目性的产品,做完之后也就不维护了,但是你想做一些基础的自动化,这个时候你就压根就不需要去考虑自动化的力度,你只要用最快的自动化方式给测试用例实现了,那就可以。这种情况下我们就不用谈力度。

    用例的力度没有说一定对,或者一定错,而一定是基于上下文去找到最适合自己的东西。对于用例的力度,

    那为什么别人能够针对某一类测试系统,或者某一类东西给出比较好的测试解决方案呐?或者说是测试的策略?那是因为感觉。经过长期积累,别人形成了对这种技术本身的一种感觉,在无形的情况下,形成一些有形有价值的东西,帮助你快速且准确地给出方案。这就比较重要了。

    最后说一下,我的《软件测试52讲》专栏已经完结了,共62篇文章,码写了26万3948个字。通过一系列行业最佳实践案例的讲解,为大家呈现一幅包括GUI/API自动化测试、测试数据平台、测试基础架构建设、性能/压力测试、代码级测试、测试新技术和大型网站架构等在内的软件测试技术全景视图。

    展开全文
  • 软件测试岗位职责

    千次阅读 2019-07-22 17:15:46
    软件测试岗位职责,明确着这个岗位的技术劳工,应该做什么,你在各种招聘明细中,可以查阅到这方面的信息。简单来讲,从劳工责任的角度,工作内容实际上就是不断的找到软件中的bug,并监督开发人员修复它们。造成...

    软件测试岗位职责,明确着这个岗位的技术劳工,应该做什么,你在各种招聘明细中,可以查阅到这方面的信息。简单来讲,从劳工责任的角度,工作内容实际上就是不断的找到软件中的bug,并监督开发人员修复它们。造成这种简单的原因,从工业生产的方面,有不同的声音,大部分人觉得,这是利于工业发展的,让测试人员不断地找到软件问题,已经实现了他们的价值;但另有小部分人觉得,软件测试岗位还应该有更大的商业价值,甚至社会价值,而作者本人更倾向于小部分人的看法。

    下面,我想更换一下“职责”这个词语,用“权责”来临时替换,说明一些观点。

    软件测试岗位权责,并不是为了发现更多的bug,而是要预防更多的问题被产生。软件测试岗位有预防问题发生的权力,因此,它才有软件质量保证的责任。权力越大,责任越大,这个道理,很多软件公司并没有想清楚,测试应该在其中起到的作用和好处。我在一些小公司任职测试经理的时候,技术部的老大经常问到:“为什么我们的软件总是有那么多的bug?”,“为什么那么多个版本过后,还是有很多问题?”之后,便通过开发人员和测试人员加班来试图解决这一问题。这种现象,在很多公司并不少见。

    那到底问题的关键在哪里呢?

    问题的关键也许就在于测试在其中的作用,到底是“发现”,还是“预防”。如果只是“发现”,那么测试人员就会对bug出现的原因不会那么关心,即使关心,也会最终因为没有责任而自省麻烦,而机械的发现bug,对于专业的测试人员,并不是一件难事;与此同时,有了帮忙“发现”问题的队友,开发人员自然而然会降低开发中的自省成本,更快的完成工作任务,即使存在较多问题,也可以随理成章的进入到bug修复阶段来补偿。但如果是“预防”,测试人员更多的责任会重新发生变化,测试人员会更多的思考bug出现的原因,怎么样“尽早”发现问题,而不至于在下一个阶段,问题的数量变成10倍。

    问题的关键还有另一个原因,这个原因同时也制约着“预防”的实施,这就是“权力”。软件测试在整个软件的生产线中,一般公司都让其处于比较被动的位置上,既要发现问题,又没有太多权力去解决问题,这里的问题,更多的还涉及到了一些由于管理不当,而产生的软件问题。很多老测试会有这样的经验,当测试一个软件产品一段时间后,自然而然就能发现很多公司管理上的本质问题,而解决这些问题,也许比督促开发同事修复bug,对产品的良好上线更有效果,但最终,有权力的解决者,也并没有解决好相关的问题。

    软件测试岗位权责,在目前的软件生产中,更多的倾向于“责”,缺少“权”的结构,导致了软件质量本身更倾向于“被动式发现”,而缺少“主动预防”。主动预防的成本相对较高,一方面是本身预防性工作在问题被成功预防时,人们才能感觉到它的价值,另一方面,软件测试岗位对预防性人才的培育环境太过缺乏,虽然,目前任何一个软件测试招聘简章上,都要求自动化、性能、安全性的测试能力,但真正到岗后,能进行相关工作的机会却非常稀少,大部分都是黑盒测试。

    软件测试岗位,应该获得更多的“权力”来真正实现“责任”。对于整个软件生产过程,我相信是更有利的一件事情。

    展开全文
  • 软件测试的一些理解

    2017-06-28 15:03:32
    现在大部分软件企业的生态链都是,软件测试属于最下游。这也决定了很多情况都必须被动接受。即使某个测试工程师理论知识丰富,辨识风险能力强,但是一个产品需求的变更就可以让他傻眼,接着很努力去适应这种节奏。...
  • 本文要点我们需要评估测试价值,评估就是观察人们的行为、与人们交谈、从根本上测试测试过程的过程。测试用例不是一个测量单位。图表并没有告诉我们它本身的意思,我们必须自己弄清楚这个图表是什么意思。你不可能...
  • [原创]我对软件测试这份工作的理解  初入职场也有几年,到2008年在新公司升职为测试经理,管理10几个人的小测试团队,虽然前几年工作主要是做为测试工程师,做具体的事;但是后来随着自己角色转变,需要带测试团队...
  • 软件测试价值提升之路”读后感

    千次阅读 2018-06-05 18:39:34
    软件测试价值提升之路,是华为测试专家杨总从另一个角度“测试的价值”整理和编写的一本书。在公司技术体系中,测试人员的价值一直是一个很有争议的话题。开发人员把产品“造出来”,市场人员把产品“推出去”,销售...
  • 混迹于测试行业这么长时间了,一直想写一篇关于软件测试的经验分享的文章,但苦于工作原因迟迟未下笔。最近终于有了些闲余时间,遂决定把自己的心路历程及所感所想记录下来,与各位同行共勉。 软件测试究竟是做什么...
  • 首先,我们了解软件测试从业者处于阶段:高级岗位、中级从业者、菜鸟小白。 高级岗位:部门leader、核心测试开发岗位等。->对应的上级是:质量部Leader(经理/总监)、技术VP->公司老板。 中级岗位:能独立...
  • 软件评测师认证(国家软考认证)和ISTQB(国际软件测试资格认证)是软件测试从业人员普遍认为对软件测试技术或管理岗位价值的证书。 软件评测师认证(国家软考认证): 软件评测师是要能在掌握软件工程与软件...
  • 我所理解的"测试"工作

    千次阅读 多人点赞 2017-11-29 10:28:33
     入行第5年了,最近发现自己心态上起了一些微妙的变化,如果在头三年,别人问我,软件测试到底是干啥的,我肯定会回答,就是测软件上bug的,当然,你的bug测得越多越好,甚至,你在测试时候如果没有发现Bug,你会...
  • 上一篇里我们讨论了测试的必需性,如果大家目前还在公司里做着测试的工作,那就说明还是落在必需的范围里面,或者至少一段时间是吧。那接下来我们看下既然需要做测试,需要做哪些事情。基于我自己的一...
  • 本节书摘来自华章出版社《软件测试价值提升之路》一书中的第1章,第1.1节,作者:杨晓慧编著,更多章节内容可以访问云栖社区“华章计算机”公众号查看。 第1部分 引 子测试工作是否有价值,这似乎是一个不值得讨论...
  • 软件测试职业规划

    万次阅读 2017-10-15 16:24:01
    软件测试职业规划 以下是转载内容。 软件测试人员的发展误区【4】  公司开发的产品专业性较强,软件测试人员需要有很强的专业知识,现在软件测试人员发展出现了一种测试管理者不愿意看到的景象:  1、开发...
  • 软件测试前景和发展方向

    万次阅读 多人点赞 2019-04-24 15:50:54
    2019最热门的软件测试趋势 毛哥(译) 放眼全球,了解技术发展的边界和趋势,有助于组织和个人的发展及竞争力的提升,偶尔看到国外某网站的一篇文章,读来颇值得参考,简单翻译过来,分享一下。 也许这篇文章会给...
  • 软件测试,想说爱你不容易

    千次阅读 热门讨论 2013-01-31 21:39:50
    客户为Cisco,出过2个以上的版本,代码量在20万行以上),功能测试、性能测试、测试自动化、测试辅助工具开发、国际化测试、本地化测试、兼容性测试、第三方测试、测试团队管理,对软件测试理解也逐渐深入。...
1 2 3 4 5 ... 20
收藏数 15,547
精华内容 6,218
关键字:

对软件测试岗位价值的理解