闲聊测试工程师

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

---

其实广泛意义上的测试工程师，核心的工做内容只有一个：业务！而核心工做方向包含两个：1. 质量 2. 效率
一切都是围绕怎么保证或提高“质量”/“效率”来思考。
质量与效率上“软”：好比研发流程、标准规范、要求规约等，又如对产品设计、技术设计的熟知度等。
质量与效率的“硬”：直接的如业务逻辑，工具/平台开发，复杂的如开发技术实现方案、架构设计等。

测试职业的最终定义：
随着技术与经验的积累，你会发现，其最终是一个面向产品业务和开发技术的，工程效率和质量度量与控制的角色。
平常工做，即拎着一个大的工具箱，适配解决不一样工件内容，予以预控或度量。

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

---

所以，若是能将本身所接触的重要业务，能够从前到后，多维度的代表，必定能成为技术型的业务专家。
如何理解这样的专家？通俗来讲，就是广度很好，深度有所限制。这实际上是很是正常的，并且符合岗位本质的。
若是我举几个栗子，相信很容易让人明白……但，我懒~

上述内容都是大白话，扯犊子的。由于不爱写非技术类内容，不喜勿喷