这是鼎叔的第二篇原创文章。
行业大牛和刚毕业的小白,都可以进来聊聊。
欢迎关注本人专栏和公众号《敏捷测试转型》,更多原创思考文章陆续推出。

鼎叔过往接触过各个团队的测试(测试开发)工程师,有时会发现,受限于不太合理的分工和培养导向,有些工程师走错了能力修炼的方向,面临职业发展的困惑选择。本篇文章就讲讲测试工程师的核心能力模型是什么,如何识别一些宝贵的能力特征,其他工程师同样可以借鉴。

不同的公司对于测试工程师的能力及发展要求,有一定的差异,但整体而言差不多,主管深入理解这些能力的定义和发展阶段的要求,才能更好的帮助团队提升基础下限,并寻求更级别的上限突破。
测试人员的核心能力可以分为两大类,专业硬能力和通用素质能力。下面将对测试核心能力的具体理解,以及如何识别和培养,给出一些可借鉴的思路。

第一部分 测试核心专业能力
大学应该掌握的高级语言编程等能力属于学科基础能力,不再赘述。

需求分析能力和测试设计能力
测试工程师的本质工作,确保深刻理解被测需求,包括它的起源,背后的用户特征,用户使用场景,有丰富的输入才能进行完善的测试分析,明确测试策略(用有限的精力覆盖最多有价值的验证点),利用多种方法设计完善的用例场景。在执行过程中还要不断的自我审视和调整下一阶段的执行策略。
测试工程师只有被人信任其设计能力,不会轻易遗漏重要用户场景,及时抓住主要风险,才能获得向上晋升的影响力。
类似的架构理解能力也是需求分析能力的拓展,充分掌握产品业务的架构,软件前后端的架构,工程师才能具备全局视角,规划策略中的测试重点,避免跨模块边界不要遗漏。
最常见的发展歧路,就是工程师变成了测试工作的项目经理,没有足够的精力分析客户需求,没有时间进行测试策略和用例设计,甚至把这些工作都给其他执行人员,自己成了甩手掌柜(监工),不了解关键的技术背景,也不能对遗漏风险做靠谱的把控。

自动化测试工具能力
这块并不是只考察原创工具平台的开发能力,鼎叔认为即使不是一个优秀的测试工具开发者,也可以获得高度认可,避免各个工程师仅仅为了晋升而做新工具、新平台。
相关考察的重点在于,自动化测试落地的调研思考和最终效果,价值体现在这几个方面:
l 是否充分了解测试用户的诉求(可能包含开发用户,可能是需要低代码平台的合作方用户)。
l 能否不开发新工具而是完全复用开源平台?理由是否充分?
l 决策使用自研平台,而不是采用商业平台的理由。
l 对各种行业工具框架的选型分析,实践案例分析。
l 是否成为制定工具/平台需求的优秀产品经理(PO)?是否有良好的工具架构设计体现?
l 是否成为工具平台建设和交付的项目经理?是否善于在团队落地新工具,数据成效斐然?

质量分析和改进能力
能否从测试过程和交付效果的表现和数据中,敏锐地找到要改进的地方,并采取专项行动,落实改进措施?典型的能力表现证据有:
l 对现有研发质量相关的流程,是否能识别浪费或低效的地方,实施改进,真实地提高了效能。
l 对阶段性的版本交付上线,能否周期地进行缺陷分析,科学分类,抓住可重点改进的预防措施。
l 整个研发流程的测试活动产生的度量数据,暴露了什么不足?
l 所有改进的效果,是长期性的,经验可复用的,还是暂时性的,局限单一问题域的?你如何用数据证明?
鼎叔看到过很多工程师的质量总结,仅仅满足于抓到了多少个问题,而没有系统分析聚类,没有试图抓住问题的共性规律,也没有逐层深挖。对高级别工程师来说,难以充分体现价值。
另外一个极端反例是,针对单个质量事故给出大而不当的解决措施,动不动要 “提高开发自测质量”,“要做好架构评审活动”,“不能夹带代码发布”,这些都是 “正确的废话”。质量改进一定是抓住每个事故的本质原因来改进,所有措施都需要在现有资源下可以持续地进行,执行者清晰的知道 how to 的步骤。
图片

专项测试能力
测试领域和知识博大精深,测试团队规模通常不大,具备专项测试能力的人才往往是很缺乏的。我们可以在招聘和人才培养中,有意识地识别具备专项测试发展潜力和强烈兴趣的人。
特定时期下,专才对于团队的价值是非常大,能弥补团队短板,满足业务特定需求,值得投入更多成本。为了让专项测试人员顺利成长,除了在能力模型中可以加以引导,在工作安排和考核上可以进行聚焦及倾斜,把这类人才从繁复的业务测试需求中抽离出来,专心向自己擅长的领域深入挖掘和实践。
主要的高价值专项测试方向有:终端专项性能分析或工具开发,服务端性能测试分析或平台开发,安全测试,AI 评测,大数据测试,中间件/组件测试,协议测试等等。

第二部分 测试核心素质能力
素质能力,也有人称为 “软能力”,“通用能力”,即不同岗位的成功都可能要依赖的重要能力。
敏捷项目管理能力
深入理解敏捷原则,在测试活动中身体力行,同时掌握项目管理的基本知识和推动技巧,才能保障测试交付的目标。

系统思考能力
测试角色在复杂项目中坚守质量标准,捍卫用户价值,又要取舍和平衡,按时输出报告,面对不同角色的压力和各类突发状况。因此系统思考能力非常关键,避免陷入越忙越乱,吃力不讨好的境地。
所谓系统思考,就是观察事情被阻碍(或者被加速)背后的闭环是如何形成的,找到关键抓手,事半功倍。复杂问题背后甚至可能有双重闭环互相影响,有兴趣的同学可以参阅彼得圣吉的书《系统思考》。
以 “如何提升外包同学的工作效率” 话题为例,抛出话题的工程师,本能想到的解决思路是提供更专业的外包培训和更耐心的辅导。但是如果我们深入理解外包效率不高的成因,是因为内部工程师自己的工作安排不过来,也不清楚如何让外包的工作更加丰富而有价值,外包同学在单调重复的工作中难以提升,产出成果缺乏变化,进一步削弱了内部工程师分派工作的积极性,这就是一个负向循环。
因此,正确的做法应该是:提升内部工程师的测试体系化水平,掌握更丰富多彩的任务类型。当手中有丰富的测试任务类型,就可以把流程成熟的,易于传播的任务给到外包团队进行尝试,外包人员也有更多的机会学习新东西,最终找到产出效率最高的任务模式。

追求极致
这听起来像是产品经理的价值观,但是对于一个优秀的测试工程师,这是值得追求的职业态度。追求极致可以有几个不同的追求方向,第一个是勘查被测试场景的蛛丝马迹,包括用户描述,环境和设备信息,消息,日志,内部状态,哪些可能导致缺陷的出现,如果隔离掉,缺陷是否会消失。
第二个方向是不断追问失效的本质,是什么导致了问题的发生,以及过往为啥会忽略,从开发层面追问这个失效是如何引入的,为什么需求设计的时候没有想到。类似的优秀表现还体现上性能问题的调试分析上,比如 5M 的内存空间泄漏或者 10 帧的流畅度损失,背后是什么原因和什么代码引起的,什么改进措施是最佳做法,进而总结出共性的调优技巧。
第三个方向是关联模块知识的追寻。面试时经常遇到测试人员针对某个事故的成因回答到 “这是其他团队负责的,我不太清楚”。经典软件事故是最好的老师,从中可以学到模块边界和协同工作的知识,也能理解业务风险的整体视角。虽然我是测试人员,但是有义务理解背后的技术原理、开发实现的思路和遇到的麻烦,不能局限于自己负责的测试模块,限制自己的成长。

除此之外,用户视角、逻辑表达、细致敏锐、快速学习、抗压能力、方法论提炼、团队协同和说服等通用能力也非常重要,这些要么在本专栏和公众号未来的文章中会深入呈现(包括本文上述提到的所有能力的优秀实例),要么暂时没有测试方面的特别关注,按下不表。


↙↙↙阅读原文可查看相关链接,并与作者交流