这是鼎叔的第四十八篇原创文章。

行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》，大量原创思考文章陆续推出。

TMQ（某某移动品质中心）公众号（后期改名为“某厂效能”），前几天我想上去翻翻老文章，发现微信公众号已经被注销，不禁心生感慨。顺便聊聊测试团队转型为谷歌式的工程效能团队，有什么坑要注意。

幸运的是，TMQ在云开发者社区的专栏还在，原创文章300多篇还在，最后一篇是2020年发表的，后面再无更新。这些文章也被传播到很多技术网站。

大约7-8年前，我和廖叔，Rufus，Cody商量怎么给咱们的测试大团队起一个响亮的技术品牌名字，最后英文简称为TMQ，我写了这么一段团队IP介绍：

TMQ是最早专注在移动APP测试的团队，在十余年的时间内承担了近十款业界领先产品测试工作，近七年的android及iOS自动化测试项目经验，为移动端转型提供了多项质量方案和关键专利。

在移动互联网火爆的那些年，咱们这个业界最早进行移动终端测试实践的测试大团队（包括孵化成功后分离出去的兄弟团队），打磨出了不少行业闻名的移动测试工具平台。如果读者没听说过，大概率不是从事移动端测试的，或者入行尚浅

包括：

优测-真机云测试平台。早期真机云测试版本（2012年）得到了卓越研发金奖，也是QA团队第一次得到这么大的奖。

BUGLY崩溃/ANR上报平台

GT-APP性能随身调测工具

移动研发管理平台RDM

Tesly众测平台，后来改成标注众包平台了

16-18年，以TMQ为IP，出版了四本以移动APP测试为主题的丛书，在从业人员的普及率还挺高，经常在其他公司的同僚桌上能看见

下面是一些个人感想。

一，公司部门技术IP确实不如个人技术IP稳定。

虽说人多力量大，但是风格不好统一，管理上不自由。一旦部门组织发生变化，目标发生变化，可能辛苦积累IP就慢慢消失了。就像以色列人把ICQ卖给了美国在线，后者的高管都说不清楚这产品扔哪去了。另外，团队输出文章缺乏稳定的人格化，有点“端着”或者官方范，亲和力不足。

二，TMQ丰富多彩的测试创新主题。

在N年前AI概念红遍各大互联网公司，TMQ的测试技术文章已经开始尝试模型化测试和智能化测试探讨了。要知道，那时不比现在，没几个QA正经学过机器学习，而现在十个计算机系毕业生，有九个做过AI实践项目。

看那些文章，感觉团队成员敢写，敢总结，敢发布，思考的启发性很不错，虽然算法和模型的深度不足，这也是很多大厂技术公众号没有的，探索的活力和勇于分享。

关于测试团队如何营造创新氛围，可以看我这两篇：聊聊如何建设团队的创新氛围，聊聊如何申请技术专利

三，测试技术团队转型为谷歌式的工程效能团队，有必要么？有什么大坑要避免？

敏捷转型其实有三大要素，质量，效率，能力。真正成功的转型是三要素都有显著提升。

在运动式的“向硅谷效能看齐”中，我们要警惕这些管理上的错误策略。

1 敏捷变革通常是非侵入式的，循序渐进的辅导，让一线团队有自治权。而不是大刀阔斧的，缺乏充分沟通的行政动作。

2 一定要懂系统测试的资深专家来参与变革，一定要懂敏捷测试四象限。

单元测试/接口测试，不能取代高层级的系统测试，也不能取代面向用户的探索式测试，读过硅谷计算机前辈的著作就会懂。可以在单元测试/接口测试上持续发力，但不能取代后者，不能大幅弱化后者。

换句话说，团队需要系统测试的专家，需要探索式测试的专家。代码/接口级别的质量，不能替代界面体验，稳定性，性能，兼容，跨功能域的复杂测试。

3 如果黑盒测试要基本上外包化，一定要培养外包的测试设计能力，探索式测试能力。对正式员工更是如此。

自动化工程能力不是银弹，解决不了测试设计能力的短板，后者更加致命。

4 不要丢掉单测/接口测试以外的测试技术遗产，相关的专家修炼不易，人才宝贵。鼓励测试人员的多样化创新。

而不是套一个先进公司模版强制人员技能转型。如上所说，测试人员的专业价值很多不是体现在工程工具上的。

未来我还会详细写一下相关的系列探讨文章。以上。