博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
闲聊测试工程师
阅读量:4977 次
发布时间:2019-06-12

本文共 811 字,大约阅读时间需要 2 分钟。

写在开头的废话:

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


其实普遍意义上的测试工程师,核心的工作内容只有一个:业务!而核心工作方向包含两个:1. 质量 2. 效率

一切都是围绕怎么保证或提升“质量”/“效率”来思考。
质量与效率上“软”:比如研发流程、标准规范、要求规约等,又如对产品设计、技术设计的熟知度等。
质量与效率的“硬”:直接的如业务逻辑,工具/平台开发,复杂的如开发技术实现方案、架构设计等。

测试职业的最终定义:

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

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


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

如何理解这样的专家?通俗来说,就是广度很好,深度有所限制。这其实是非常正常的,而且符合岗位本质的。
如果我举几个栗子,相信很容易让人明白……但,我懒~

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

转载于:https://www.cnblogs.com/hailongchen/p/11001249.html

你可能感兴趣的文章
Visual LISP 第4章 有关Visual LISP的基本操作(1)进入和退出Visual LISP
查看>>
latexdiff中的大坑:字符编码问题
查看>>
Storyboard、xib中的UIScrollView使用autolayout,使其能够滚动
查看>>
PAT 1050 螺旋矩阵(25)(代码)
查看>>
Linux基本操作命令
查看>>
Java线程同步的方式
查看>>
Perl map()函数
查看>>
RelativeLayout练习
查看>>
Tomcat 的端口被占用的解决办法
查看>>
10. dede5.7标签调用说明
查看>>
bzoj 3207 可持久化线段树+hash
查看>>
解决 Python.h:没有那个文件或目录 错误的方法
查看>>
【Demo 0023】改变窗体的位置, 大小及Z-ORDER
查看>>
【原创】Hibernate通过实体类自动建表时type=MyISAM的问题
查看>>
MySQL系列(五) 锁
查看>>
【图解漏洞】图解跨站脚本攻击(XSS)原理
查看>>
sql 查找某个字符在字符串中第N次出现的位置
查看>>
编译原理:引论
查看>>
LFM 隐语义模型
查看>>
unwrapped与wrapped变量取值的问题
查看>>