今天逛论坛的时候看到了一篇帖子，是关于 MTSC 大会的问题。近几年，我也参加了不少的行业峰会，不管是作为听众，还是作为分享嘉宾，都会有不少的收获，总体来说，还是感谢这些主办方的。聊聊我自己的一些看法。
在参与这些大会的时候，经常听到的，都是一些高大上的名词，比如求实例化、活文档、测试分层、质量内建、研发效能。但是，在现实的团队里，你可能遇到的是一句话需求。文档？自己抓包。点点点，都没有足够的时间。然后是质量内建，说质量是团队的事情，但是更多的时候是质量是测试的事情，虽然这句话不好听，但是大概率是这样的。
理想和现实差距很大，我们需要认清楚，也就是很多同学提到的，大会的内容不能落地的情况，但是不能因为现实的困难就忘记了理想。在这个过程中有两种情况，一种是停滞不前，成为炮灰，另一种是跑得太快，成为先烈。
第一个案例，这是 2015 年我的老大参加业内的分享，看到人家在玩精准测试。现在精准测试已经很普遍，这两年说得很多，但是那时是 2015 年。大概七年前，大家想想七年前这个概念我们怎么玩？我们老大觉得很好，收益很明显，那就开干。开始组团队，招人，研究、学习，跟业务配合，干得热火朝天，一开始信心满满。但是到 2016 年底的时候发现做不下去了。干不下去的原因很多，业务、技术的原因都有，很大的原因大家不知道怎么玩了，再强调一下这是 2015、2016 年，当时 Jacoco 还没有多久，那个时候我们去玩这个东西，风险是非常大的。所以我们失败了。做出来的东西只能在一小段代码上做个小样。大概到 2016 年底的时候这个项目就停掉了，后来整个团队裁掉了，这个就是所谓的先烈。为了这个事情找了很多人。所以有时候看到一些新的技术，特别是你的领导热衷这个实践的时候，很多时候会发现干着干着就干不下去了。这是先烈的案例。
第二个案例，是一个自动化测试平台的落地实践，整体的功能点也是从大会分享中获取了一些灵感，所有的技术点，拆开来看，都挺平淡无奇的。大部分大家都在做，但是如果能够把这些东西串起来，做成一个平台化的东西，或者说能做到持续测试、持续反馈。我们可以结合团队的一些技术能力，一些理念，做一些小而美的东西，真正有价值的东西，可能比高大上的东西要好。当时包括我们的反馈，知识库的处理，部分功能还是有自己的特点，有一定的先进性，但是步子迈得的没有那么大，结合现状，做成这么一个平台，最后这个平台成功落地了。
当大家在做技术选型的时候，或者说想推先进技术的时候可能要考虑的几个点。
能不能解决当下的痛点，这是我们作为 leader 首先要考虑的点，就是我们为什么要用它？它能解决什么问题？我们都在聊自动化、测试、全链路压测，这些东西我们用不用？它给当下项目团队带来什么东西？不是说因为别人用所以我们就必须要用。这从团队管理的角度来说并不一定合适，我们做一些创新，一定是当下单项目的考量，一定是为了解决什么问题，很少为了做一些理想的东西，当然也有这种情况。
关注一下团队技术是否匹配？因为技术还是需要落到人去做，虽然说我们有成熟开源的工具，这种情况下我们团队是否 hold？后期如何维护？我们团队的人如何去玩这个事？这都是需要我们考量的事情，还有，我们的基本设施是否跟上了，如果没有，是不是可以尝试这些基础设施的完善。
业务能否达到适配要求？当你做一些推广的时候，你可能要关注地是业务能否配合？比如全链路压测，很多时候涉及业务代码修改。这些对业务团队来说没有线下的价值，你怎么说服业务团队配合你做这个事？这也是一个很重要的事情。
是否可以做到举一反三？比如说有一些基础是否可以复用？它除了能做这个是不是可以做其他的事情，这些都要在我们的方案中想清楚，通过一些技术的引入解决技术资源的整合也好，或者团队资源的整合也好，我们可以更多地考虑这种事情。
大会分享的基本上都是思路，至少是别人成功落地过的实践，是具有参考价值的。至于价值的多少，在于你想了解的是什么，你自己的认知在哪里。你不能指望 1 小时左右的分享你就能落地实践了，更多的是指明了一个方向，让你知道这条路是可行的。这个无关大小，不管是大峰会还是小分享，都是一样的。
关于票价的问题，在大会前期的宣传上都会有相关的议题，你觉得值，就买，不值，就等后续的 PPT 或者视频。纯属个人行为，又没硬推给你，对吧。要有自己的判断。
最后，再次感谢此类大会的举办，让测试人有个了解前沿技术和思维的机会。让测试看到了更多的可能性。不要被 “测试” 这个标签所限定。测试也不仅停留在业务上的，虽然它很重要。