• 读“去 QE 时代,测试开发者该如何迎难而上?”有感


    原文链接在此:
    https://mp.weixin.qq.com/s/ynMB2kVQSyA0e360QBrwAQ
    是直播“去 QE 时代,测试开发者该如何迎难而上?”的文字整理稿,标题也变成了“为何从开发转测试,并坚持了16年?”

    本文原创首发于个人独立博客,并同期搬运到简书等平台。
    博客地址: http://mmcatt.github.io

    为什么写这么一篇感悟呢,也是因为作者这篇文章给我解了惑。
    最近几个月以来,一直在思考测试行业的发展,如何成长,如何走的更深更远。
    也去阅读了很多国外的文献,发现其实测试能够做的事情很多。但是这些文献资料,都是侧重于自己的主题,大量的阅读资料,反而使自己迷失其中,越发理不清思绪,没有体系,也越发不清楚测试的核心价值所在。

    • 是自动化测试吗?其实自动化测试能够做的事情比较有限。
    • 是测试架构师吗?感觉这个概念还是有些单薄。
    • 是测试开发吗?那么测试开发应该具体的做些什么呢?

    这些问题一直萦绕在我的脑袋中,直到看到这篇文章中提到的"去QE","工程效能"以及相关解读,眼前的迷雾逐渐变得清晰起来。

    故写下这篇文章,也希望同行小伙伴们,能从作者原文或者我的感悟中受益。

    首先,测试可以分为三大类:

    1. 传统意义上的基于业务功能的测试,也就是手动测试。或者有些测试同学自嘲为"点点点"。
    2. 自动化测试。这部分主要就是把手动的脚本翻译成自动化脚本。
    3. 测试开发,这是很大的一块。比如测试平台、测试服务,测试基础架构的开发。基础架构又包括什么呢?比如一些类似云测的服务。

    那么,就我自己的从业经验,以及平常接触到的一些同行者。大部分公司一定会做第一块,功能测试,然后基本上也不同程度的做了第二块,自动化测试;很少有公司在做第三块,或者比较成体系的在做第三块。
    也很正常,有些公司刚起步的时候不重视测试,可能管理层也未必特别懂测试(比如不少公司的测试部门是由开发老大兼任管理),或者对自动化测试抱有了过高甚至不切实际的希望。

    基于作者的理解,其实我们应该很清楚了,测试的发展方向是第三块:测试开发。

    之后作者文中又提出一个名词:去QE时代。这个概念在国内可能还很新,但是在如Google、Facebook等这样的公司,已经正在做这些事情,并且已经有成果真正落地了。

    我们知道,谷歌的任何一个测试工程师拉出来,都是有能力去做开发的。因此是否"去QE",其实和组织的整体情况以及体系密切相关,并不一定适用于每个公司。但是我们可以参考一下,在这样的一些公司中,他们是如何玩儿测试的。
    quqe.jpg

    看这个图,就知道去QE的公司,其实也不是没有测试,只是把API, GUI测试都交给开发来做了,只是留了一小部分任务,探索性测试,给纯粹的测试人员。
    所以这些公司并不是不做测试,而是换了一拨人来做测试而已。

    那么,如果开发都可以去做测试的活儿,测试应该做些什么,才能体现自己的独特价值呢?作者随后提到了工程效能团队这么一个概念。

    这个现在是很流行的,包括Google也在运行。那么第三块测试开发的人,就会到这个团队中去。
    那么好玩的地方来了,从这里就可以清楚的看到,测试的价值,其实是给开发赋能。比如:去提供服务让开发创造想要的数据,提供部署好的测试环境,让开发人员方便的打包并自动化部署完成,等等。就是去做一些平台化服务化工具化的东西,提高开发本身的效率。Google 就是业内做的非常成功的一家公司。

    作者还提到,Google过去有一个页内非常知名的大会,叫做GTAC,它是Google在全球的自动化测试大会,但是却在2017年停掉了。为什么呢,因为Google意识到,单靠测试已经不是最好的途径去提高整个企业研发的效能了。于是,在2018年,这个会议将会以工程效能为Topic,而不再是一个测试大会。

    看到这里,我眼前一下子开阔了起来,所以要从提高整个企业研发的角度,来考虑这个职业的发展。那么,路子就宽广的太多了!
    比如,努力让自己成为一个有能力去做这些事情的人,去成为工程效能团队的一员。
    或者,考虑让自己的组织慢慢向这个角度靠拢。
    只是随便想想,就觉得有太多的事情可以做了,不再是局限于过去的业务逻辑,自动化测试工具,测试平台开发这些小视野中。而是站在一个更高的角度俯视,寻找着自己可能向上攀登的途径。

    作者在本文中,对于学习路线也是做了介绍的,我这里也就简单的整理一下。

    第一类人是去做业务专家,如果想往产品经理方向发展,可以去走这条路子。
    第二类是开发测试工程师,更多的是对工具的熟悉。但是其实最重要的一点,是要去了解这个工具的原理,从而才能够去做一些更深层次的事情。
    第三类就是测试开发工程师。作者表示,这部分说白了其实就是开发,但是开发的产品是为测试服务的。所以这类人的成长路径,就是一个开发的成长路径。

    分析作者给出的成长路线,结合前面所说的"工程效能团队",其实就会明白,测试和开发是不分家的。想做好测试,其实也需要做好开发。但是最终的目的是不变的,就是提升自己所在企业研发的效能。

    2018年07月24日 补充心得:
    关于第一类人,业务专家,今天我结合行业的发展趋势,又有了新的心得。
    我个人觉得,往业务专家发展,可能路子不如另外两类来得宽广。因为既然是业务专家,肯定就是局限在某个具体的行业内。
    但是行业的发展是有周期的,比如前些年通信行业很红火,而最近这些年互联网行业则比通信行业红火。
    那么,如果你选择了业务专家的路线,你能保证这个行业长青吗?很难。一个行业或许能火三年,那么十年呢?二十年呢?
    从这个角度考虑,是不是对未来,看的更清晰了一点呢?

    对了对了,本文的作者也是开设了软件测试相关的专栏课程,有兴趣的,也可以扫图片下面的二维码,加入进来我们一起学习!
    52.jpg

  • 相关阅读:
    Jzoj4822 完美标号
    Jzoj4822 完美标号
    Jzoj4792 整除
    Jzoj4792 整除
    Educational Codeforces Round 79 A. New Year Garland
    Good Bye 2019 C. Make Good
    ?Good Bye 2019 B. Interesting Subarray
    Good Bye 2019 A. Card Game
    力扣算法题—088扰乱字符串【二叉树】
    力扣算法题—086分隔链表
  • 原文地址:https://www.cnblogs.com/cynthiaw/p/9391911.html
Copyright © 2020-2023  润新知