前几天在某个测试技术交流群，有大佬抛出了一个问题：如果抛开技术不谈，如何衡量测试的Level？简单理解就是：排除技术因素，如何衡量测试工程师的能力达到什么层次？或者说用什么来评估测试工程师核心竞争力？
如果从企业的角度来讲，这就涉及到一个岗位匹配度模型和晋升机制的问题。什么能力做什么事情，让合适的人做合适的事情。从个人角度来讲，明确这点，能更好的在求职市场以及职场有个更明确的定位和职业规划。
这篇文章，我想谈谈我对测试工程师核心竞争力的一些思考和想法。
技术
既然上面的问题提到了技术，那我就先聊聊技术方面的因素。
首先，软件测试岗位是一个技术岗位，这点毋庸置疑。那对于技术岗位来说，技术的底子或者说能力，是很重要的。如何评估一个软件测试工程师的技术能力呢？在求职或者企业招聘时，通常关注如下几点：
学历：学习能力；
技术栈：会什么技术；
项目经验：利用技术解决过哪些实际的具体的问题；
大厂履历：业务复杂度更高，高流量带来的技术挑战范围更广，深度要求更高；
沟通表达：现代职场需要多人协同，高效沟通协调才能解决更复杂的问题和工作；
参照上述几点，我对技术的定义是：技术是工具，利用工具解决问题是能力，能力高低取决于如何更高效的利用工具解决更复杂的问题。
在我看来，技术是所有技术岗位或技术工种的基本面，就像盖房子需要打地基一样。万丈高楼平地起，技术就是打地基。技术很重要，但技术只是重要因素之一，利用技术更高效的解决更复杂的问题，才是衡量技术能力的标准。
业务
聊完技术，接着聊聊我对业务的理解。
不同企业的业务类型不尽相同，团队面临的业务挑战也不一样。
大家都知道，互联网技术岗位，日常的工作就是完成需求，需求的来源就是实际的业务场景和挑战。上面我提到了利用技术解决问题，这里的问题就是实际的来源于业务迭代带来的挑战。
我在面试候选人时，会经常问到下面几个问题：
介绍下最近做过的项目；
你在其中担任什么角色；
在项目中遇到过哪些问题；
你是如何解决这些问题的；
解决问题背后的思路是什么；
有没有其他解决问题的方案；
从上面几个问题展开来讲，我希望候选人能对项目背景、项目目标、技术选型、面临的挑战、要解决什么问题、分析问题的思路、典型问题的处理细节等多方面来进行介绍说明，便于我评估候选人的技术能力及对业务的熟悉程度。
你看，其实除了技术，对业务的熟悉和理解也很重要。
我的观点是，技术本身并没有具体的价值，技术能解决多大的业务问题，就具备多大的价值。
流程
前文中我提到了现代职场需要多人协同，高效沟通协调才能解决更复杂的问题。每个员工在之前工作中所遵守的流程、工作沟通习惯或许都各有差异。而流程的目的就是尽可能的是团队在解决问题的过程中，尽可能保持节奏和目标一致。
这里引用我在之前的文章《测试工程师的职场发展二三谈》中关于流程的一段描述：
流程是什么？
保障团队目标达成的最佳实践，因人/团队/业务类型/迭代速度/资源紧张程度而异。
为什么要有流程？
没有流程会导致团队中个体各自为战，目标不统一，进度不协调，资源配给失衡而导致交付质量下降。
流程能解决什么问题？
保障团队或群体在大方向上保持一致，尽可能降低由于团队人员能力、认知水平、资源不足、意外情况导致的项目延期或质量下降。
流程能带来什么保障？
保障工作中遇到沟通或者争执时你可以有底气的据理力争，虽然不一定能扭转局势，但在一定层面上，会哭的孩子有奶吃，偶尔学会受委屈给领导看，也是以退为进保障自己利益不受太多损失的技巧。
如何高大上的理解流程？
风险可识别+问题可追踪+结果可验证+数据可量化！
总结
聊到这里，我要表达的核心观点已经在上文陈述了，这里做个总结。
测试工程师的核心竞争力是：将技术作为底层能力，在尽可能熟悉业务的情况下基于技术解决问题，过程中不断优化流程，保持高效的沟通，保障最终交付产出物的质量和交付过程效率。
核心竞争力最终又回到了QA这个岗位的本质：质量+效率。
当然，实践过程中，要关注过程，但结果是最终唯一可量化竞争力的指标
如果你不想一个人野蛮生长，找不到系统的资料，问题得不到帮助，坚持几天便放弃的感受的话，可以点击下方小卡片加入我们交流群，大家可以一起讨论交流，里面会有各种软件测试资料和技术交流。
敲字不易，如果此文章对你有帮助的话，点个赞收个藏来个关注，给作者一个鼓励。也方便你下次能够快速查找。