灌水 前沿大会给我带来了什么

random
random
订阅者
10532
文章
0
粉丝
测试交流3206字数 1657阅读5分31秒阅读模式

今天逛论坛的时候看到了一篇帖子,是关于 MTSC 大会的问题。近几年,我也参加了不少的行业峰会,不管是作为听众,还是作为分享嘉宾,都会有不少的收获,总体来说,还是感谢这些主办方的。聊聊我自己的一些看法。

01 理想与现实的差距

在参与这些大会的时候,经常听到的,都是一些高大上的名词,比如求实例化、活文档、测试分层、质量内建、研发效能。但是,在现实的团队里,你可能遇到的是一句话需求。文档?自己抓包。点点点,都没有足够的时间。然后是质量内建,说质量是团队的事情,但是更多的时候是质量是测试的事情,虽然这句话不好听,但是大概率是这样的。文章源自玩技e族-https://www.playezu.com/239603.html

理想和现实差距很大,我们需要认清楚,也就是很多同学提到的,大会的内容不能落地的情况,但是不能因为现实的困难就忘记了理想。在这个过程中有两种情况,一种是停滞不前,成为炮灰,另一种是跑得太快,成为先烈。文章源自玩技e族-https://www.playezu.com/239603.html

02 发生在自己身上的两个案例

第一个案例,这是 2015 年我的老大参加业内的分享,看到人家在玩精准测试。现在精准测试已经很普遍,这两年说得很多,但是那时是 2015 年。大概七年前,大家想想七年前这个概念我们怎么玩?我们老大觉得很好,收益很明显,那就开干。开始组团队,招人,研究、学习,跟业务配合,干得热火朝天,一开始信心满满。但是到 2016 年底的时候发现做不下去了。干不下去的原因很多,业务、技术的原因都有,很大的原因大家不知道怎么玩了,再强调一下这是 2015、2016 年,当时 Jacoco 还没有多久,那个时候我们去玩这个东西,风险是非常大的。所以我们失败了。做出来的东西只能在一小段代码上做个小样。大概到 2016 年底的时候这个项目就停掉了,后来整个团队裁掉了,这个就是所谓的先烈。为了这个事情找了很多人。所以有时候看到一些新的技术,特别是你的领导热衷这个实践的时候,很多时候会发现干着干着就干不下去了。这是先烈的案例。文章源自玩技e族-https://www.playezu.com/239603.html

第二个案例,是一个自动化测试平台的落地实践,整体的功能点也是从大会分享中获取了一些灵感,所有的技术点,拆开来看,都挺平淡无奇的。大部分大家都在做,但是如果能够把这些东西串起来,做成一个平台化的东西,或者说能做到持续测试、持续反馈。我们可以结合团队的一些技术能力,一些理念,做一些小而美的东西,真正有价值的东西,可能比高大上的东西要好。当时包括我们的反馈,知识库的处理,部分功能还是有自己的特点,有一定的先进性,但是步子迈得的没有那么大,结合现状,做成这么一个平台,最后这个平台成功落地了。文章源自玩技e族-https://www.playezu.com/239603.html

03 落地实践需要关注的信息

当大家在做技术选型的时候,或者说想推先进技术的时候可能要考虑的几个点。文章源自玩技e族-https://www.playezu.com/239603.html

  1. 能不能解决当下的痛点,这是我们作为 leader 首先要考虑的点,就是我们为什么要用它?它能解决什么问题?我们都在聊自动化、测试、全链路压测,这些东西我们用不用?它给当下项目团队带来什么东西?不是说因为别人用所以我们就必须要用。这从团队管理的角度来说并不一定合适,我们做一些创新,一定是当下单项目的考量,一定是为了解决什么问题,很少为了做一些理想的东西,当然也有这种情况。文章源自玩技e族-https://www.playezu.com/239603.html

  2. 关注一下团队技术是否匹配?因为技术还是需要落到人去做,虽然说我们有成熟开源的工具,这种情况下我们团队是否 hold?后期如何维护?我们团队的人如何去玩这个事?这都是需要我们考量的事情,还有,我们的基本设施是否跟上了,如果没有,是不是可以尝试这些基础设施的完善。文章源自玩技e族-https://www.playezu.com/239603.html

  3. 业务能否达到适配要求?当你做一些推广的时候,你可能要关注地是业务能否配合?比如全链路压测,很多时候涉及业务代码修改。这些对业务团队来说没有线下的价值,你怎么说服业务团队配合你做这个事?这也是一个很重要的事情。文章源自玩技e族-https://www.playezu.com/239603.html

  4. 是否可以做到举一反三?比如说有一些基础是否可以复用?它除了能做这个是不是可以做其他的事情,这些都要在我们的方案中想清楚,通过一些技术的引入解决技术资源的整合也好,或者团队资源的整合也好,我们可以更多地考虑这种事情。文章源自玩技e族-https://www.playezu.com/239603.html

04 关于是否值得

大会分享的基本上都是思路,至少是别人成功落地过的实践,是具有参考价值的。至于价值的多少,在于你想了解的是什么,你自己的认知在哪里。你不能指望 1 小时左右的分享你就能落地实践了,更多的是指明了一个方向,让你知道这条路是可行的。这个无关大小,不管是大峰会还是小分享,都是一样的。
关于票价的问题,在大会前期的宣传上都会有相关的议题,你觉得值,就买,不值,就等后续的 PPT 或者视频。纯属个人行为,又没硬推给你,对吧。要有自己的判断。文章源自玩技e族-https://www.playezu.com/239603.html

最后,再次感谢此类大会的举办,让测试人有个了解前沿技术和思维的机会。让测试看到了更多的可能性。不要被 “测试” 这个标签所限定。测试也不仅停留在业务上的,虽然它很重要。

 
评论  3  访客  3
    • iceman03
      iceman03 9

      说的很有道理,很多大厂分享的高大上的课题,实际上是大厂研发部门的成果对测试团队的赋能罢了,中小公司的测试看看,长长见识就可以了。那些把平台的优势当成自己的能力,然后嘲笑别人不努力,没落地的都是脑残。

      • JoyMao
        JoyMao 9

        去过 qcon、qecon 一类的,看到各类大厂说自己的 devops、全链路、智能自动化等等高大上的分享,一开始会很羡慕,但细细一想,这些东西都是有局限性的:业务运营的支撑、技术水平、人力物力…都限制了在其他公司的落地,盲目尝试最后落了个鸡飞蛋打的下场。

        但我们能做的是从大会的分享中汲取各类创新的思维和技巧,结合自身部门的问题或瓶颈来寻找方法来解决。

        从个人来讲,在我们这种不大不小的公司中,尤其是业务线的测试,对大平台的建设没有兴趣。而比较推崇楼主所言的 “小而美的工具或小平台”,准确的说是 “实用工具链”,各种工具能灵活运用各种类型的测试,这并不会比大平台效率降低。

        反而把一些列工具强行整合的大平台,前期开发量大(整合时考虑的情况会很多,规则会很复杂),后续如果研发模式改变,子工具、中间件、插件的升级带来的整个平台的维护量也很大,对以发展业务为主的公司来说,这些都是极大的成本。

        • CKL的思考
          CKL的思考 9

          https://testerhome.com/topics/34288 原话题

        匿名

        发表评论

        匿名网友
        确定

        拖动滑块以完成验证