闲聊测试工程师

写在开头的废话：

之前已经讲过技术工程师的能力模型。随着公司业务的飞速发展，行业中的开发技术变革，此次我想更多的聊聊测试工程师这类的存在。
相信绝大多数的测试工程师，或者感觉自我良好（不知道除了编码开发，还差在哪里），或者遇到了无法突破的瓶颈，至少自我从业来，尤其近三年的招聘情况来看，大抵是如此的。
那为什么会有这样的现象？主要是平台与日常工作内容，决定了这样的脉络，最终就让视野格局或是思维，相对容易落在了低处。
探索与洞察力——“知”！技术人毕竟是需要折腾的，知其存在知其方向，还有知其原理，这是决定思维上限的根因。到底知道多少，知道哪些？
学习力——“得”！简单点，就是如何转换内容，变成自己的。

其实普遍意义上的工程师，核心的工作内容只有一个：业务！

而核心工作方向包含两个：1. 质量 2. 效率

一切都是围绕怎么保证或提升“质量”、“效率”来思考。

质量与效率上“软”：比如研发流程、标准规范、要求规约等，又如对产品设计、技术设计的熟知度等。
质量与效率的“硬”：直接的如业务逻辑的把握，测试方案的有效性，工具/平台开发，复杂的如开发技术实现方案、架构设计等。

测试职业的最终定义：

随着技术与经验的积累，你会发现，其最终是一个面向产品业务和开发技术的，工程效率和质量度量与控制的角色。
日常工作，即拎着一个大的工具箱，适配解决不同工件内容，予以预控或度量。
即：度量、分析、控制、纠偏(指导)

然鹅，这样的标准，是非常难触达的。或者万精油万事不精，或者是神一样的存在 ：）

因此，如果能将自己所接触的重要业务，可以从前到后，多维度的表明，一定能成为技术型的业务专家。

如何理解这样的专家？通俗来说，就是广度很好，深度有所限制。这其实是非常正常(符合事物规律)的，而且符合岗位本质的。

那业务专家又是什么样子？首先应该熟知的是该业务对应的行业(即业态)，接着熟悉了当前组织平台的业务特点和模式，并能佐证/规划未来 3 -6 个月的业务动向、模式、优劣势等