测试八年|对业务测试人员的一些思考

2024-01-12 23:12

本文主要是介绍测试八年|对业务测试人员的一些思考,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

自从事测试工作八年多以来,经历过三个部门多条业务线,也经历过测试转型再回到测试,在此过程中对测试工作和角色的认知也逐步有些思考,想把这些思考分享给大家,希望为业务测试同学提供一些有价值的思路。

一、质量保障的本质是什么
质量保障有很多工作,如发布前对业务需求的功能测试、性能测试、a/b test等,如发布后对线上的功能回归、冒烟巡检、异常监控等,我们做这些工作都围绕着“缺陷发现”,尽可能去发现系统潜在的bug,这似乎就是质量保障的所有内容和目的,但是可以跳出这些具体的工作内容,质量保障的本质到底是什么?

我认为质量保障的本质:

是一个尽力穷尽各种手段,不断去“证伪”的过程;

是一个在有限条件和时间内,尽力将线上发生问题/故障的概率降低到最小的过程;

是一个站在风险控制的角色上,尽力提前发现/披露所有质量隐患的过程,并将出现质量问题的损失降低到最小的过程;

总结:质量保障的追求不是发现所有的bug、解决所有的风险,而是确保即使触发了bug也不会带来恶劣的影响,在此基础上力求去发现尽可能多的bug -> bug 触发概率降到尽可能低 -> 触发bug后带来的损失降到尽可能小

二、测试过程的本质是什么
一线业务测试人员的大部分工作都在支撑业务的交付,从理解prd和技术方案,到给出测试方案,执行测试方案、发现bug、验证bug再到发布后的回归验证,这是一个业务测试人员的大部分工作模式和流程,那么这个过程的本质是什么?我的理解是这一个词“ROI”。

测试过程的本质是努力寻找质量缺陷发现与资源投入的平衡点,这里的资源投入不单指测试的资源投入,而是指业务交付上所有参与者的资源投入,所以在一定程度上是可以或者说是需要牺牲长尾缺陷的,我们的追求也应该是不断去提高这个ROI,同时做好线上风险防控。

三、测试角色的价值
回答这个问题之前,我们需要先理清以下几个问题:

1)测试角色的价值由什么决定?受什么影响?
取决于业务特性对质量的需求:不同的业务特性对质量的诉求不同,这取决于业务的用户群体和规模、业务的金融风险、业务迭代导致出问题的概率和影响面等因素。

取决于业务发展状态、技术架构成熟度:一般来说,当一个业务处于刚起步、高速发展时,技术由于需要快速满足业务的需求,架构设计乱、基础建设差,此时质量问题较多,也就强依赖测试角色来做强力保障,而后随着业务稳定、技术基建完善、线上保障手段丰富,会在一定程度上减少对测试角色的依赖。

2)测试这一工作是否可以转移/测试角色是否可以省略?可/需转移的决定因素是什么?
首先答案是肯定的,可以转移或者省略,虽然不一定是好的选择~

业务对质量的诉求:业务的特性或者发展到一定程度,减弱对质量保障活动的需求。

线上风险的可控性:业务和技术成熟稳定,有比较可靠的线上风险控制能力。

质量活动的成本:在业务能够承受一定质量风险的前提下,质量保障活动的成本需要降低,并且转移的成本比维持现状要低。

3)如何体现测试角色的价值?
反向思考:今天这个业务如果没有测试角色,会怎么样?业务会跑得更快更好吗?

我们站在测试角色上,可以反思:

测试能力:

对所负责业务是否足够熟悉,是否能站在独特视角【区别于产研】来提出质量风险?

是否拥有一定的技术壁垒和门槛,是否可以被高级外包/研发替代?

测试应尽之责是否做到位并且获得良好反馈,测试的职责范围是否有扩展到“测试过程”之外的领域?

交付效率:

在业务需求繁重且紧迫情况下,测试是在起正向作用还是负向作用?

交付遇到阻塞问题或者困难时,测试起到什么作用?
综上所述,测试角色的价值:

a.业务发展需要测试角色,进行质量保障活动来降低质量风险 【客观】

b.组织在成本范围内,可以组建并维持测试角色 【客观】

c.测试角色可以用高ROI完成质量保障活动,并具备较高成本的不可替代性

【主观】

因此我们只能通过以下两个方向来提升测试价值的传输与外化:

提升ROI:以极致高的效率来发现缺陷,用高效的手段来证伪

在成本控制前提下,对质量贡献是正向的;

在交付周期内,对效率提升是正向的;

提升可替代的成本:不断变革先进生产力,努力转化生产关系

努力将测试的职责扩大;

不断研发新技术、新手段,提高技术壁垒;

与业务发展强绑定,力争成为业务不可或缺的生产力;

以上三个问题是对测试工作的一些思考,那么对于我们一线业务测试人员应该具备哪些能力,才能够去提升我们角色的价值?以下是我对三个层次测试人员的理解,可以分别从业务熟练度、测试方案与风险控制能力、合作协调能力、技术能力这四个维度去对照:

一个合格的业务测试人员应该具备哪些能力 【熟练度 完成度】

a.对所负责的业务线,产品业务逻辑和技术实现细节非常熟悉;

b.对日常测试流程及方案,熟悉并能顺利完成,能够主动解决卡点问题;

c.有一定的风险把控意识;

d.能与各方合作协调,顺利推动需求交付;

一个优秀的业务测试人员应该具备哪些能力 【owner意识 合作共赢】

a.具备业务owner视角和意识,能提出质量风险并给出建议;

b.能承担较复杂项目的测试一号位角色,能制定合理的质量保障方案;

c.能从全链路视野去提前预警风险;

d.能与各方协调合作良好,通过技术手段有效解决和减少交付过程中的卡点问题;

一个卓越的业务测试人员应该具备哪些能力【把控力 创新力 影响力】

a.打破思维局限和业务壁垒,能对业务所涉及的全链路通盘熟悉、风险把控;

b.能根据业务特性和质量风险短板,制定并落地合理化的质量保障体系化方案;

c.能更多承担除“测试过程”以外的质量保障工作,如大促稳定性保障、线上问题发现与处理等;

d.能跨团队、跨部门高效协作,有更多的“利他”思维,能通过创新型手段解决全链路题,并建立技术影响力;

以上是我对测试工作和角色的一些思考沉淀,希望对大家有所帮助,并能够驱动大家在工作中不断思考:

1.我当前负责的业务,对我的依赖程度有多大?具体是在哪些方面依赖我?

2.我测了10个、100个、1000个业务需求的差异是什么,对业务及对我自身的提升是什么?

3.我作为业务测试角色的核心竞争力是什么、有多大?

总结:

感谢每一个认真阅读我文章的人!!!

作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。

文档获取方式:加入我的软件测试交流群:1007119548免费获取~(同行大佬一起学术交流,每晚都有大佬直播分享技术知识点)

这份文档,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!

以上均可以分享,只需要你搜索vx公众号:程序员雨果,即可免费领取

这篇关于测试八年|对业务测试人员的一些思考的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/599468

相关文章

性能测试介绍

性能测试是一种测试方法,旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试,可以确定系统是否能够满足预期的性能要求,找出性能瓶颈和潜在的问题,并进行优化和调整。 发现性能瓶颈:性能测试可以帮助发现系统的性能瓶颈,即系统在高负载或高并发情况下可能出现的问题

字节面试 | 如何测试RocketMQ、RocketMQ?

字节面试:RocketMQ是怎么测试的呢? 答: 首先保证消息的消费正确、设计逆向用例,在验证消息内容为空等情况时的消费正确性; 推送大批量MQ,通过Admin控制台查看MQ消费的情况,是否出现消费假死、TPS是否正常等等问题。(上述都是临场发挥,但是RocketMQ真正的测试点,还真的需要探讨) 01 先了解RocketMQ 作为测试也是要简单了解RocketMQ。简单来说,就是一个分

【测试】输入正确用户名和密码,点击登录没有响应的可能性原因

目录 一、前端问题 1. 界面交互问题 2. 输入数据校验问题 二、网络问题 1. 网络连接中断 2. 代理设置问题 三、后端问题 1. 服务器故障 2. 数据库问题 3. 权限问题: 四、其他问题 1. 缓存问题 2. 第三方服务问题 3. 配置问题 一、前端问题 1. 界面交互问题 登录按钮的点击事件未正确绑定,导致点击后无法触发登录操作。 页面可能存在

业务中14个需要进行A/B测试的时刻[信息图]

在本指南中,我们将全面了解有关 A/B测试 的所有内容。 我们将介绍不同类型的A/B测试,如何有效地规划和启动测试,如何评估测试是否成功,您应该关注哪些指标,多年来我们发现的常见错误等等。 什么是A/B测试? A/B测试(有时称为“分割测试”)是一种实验类型,其中您创建两种或多种内容变体——如登录页面、电子邮件或广告——并将它们显示给不同的受众群体,以查看哪一种效果最好。 本质上,A/B测

【编程底层思考】垃圾收集机制,GC算法,垃圾收集器类型概述

Java的垃圾收集(Garbage Collection,GC)机制是Java语言的一大特色,它负责自动管理内存的回收,释放不再使用的对象所占用的内存。以下是对Java垃圾收集机制的详细介绍: 一、垃圾收集机制概述: 对象存活判断:垃圾收集器定期检查堆内存中的对象,判断哪些对象是“垃圾”,即不再被任何引用链直接或间接引用的对象。内存回收:将判断为垃圾的对象占用的内存进行回收,以便重新使用。

业务协同平台--简介

一、使用场景         1.多个系统统一在业务协同平台定义协同策略,由业务协同平台代替人工完成一系列的单据录入         2.同时业务协同平台将执行任务推送给pda、pad等执行终端,通知各人员、设备进行作业执行         3.作业过程中,可设置完成时间预警、作业节点通知,时刻了解作业进程         4.做完再给你做过程分析,给出优化建议         就问你这一套下

深入解析秒杀业务中的核心问题 —— 从并发控制到事务管理

深入解析秒杀业务中的核心问题 —— 从并发控制到事务管理 秒杀系统是应对高并发、高压力下的典型业务场景,涉及到并发控制、库存管理、事务管理等多个关键技术点。本文将深入剖析秒杀商品业务中常见的几个核心问题,包括 AOP 事务管理、同步锁机制、乐观锁、CAS 操作,以及用户限购策略。通过这些技术的结合,确保秒杀系统在高并发场景下的稳定性和一致性。 1. AOP 代理对象与事务管理 在秒杀商品

Verybot之OpenCV应用一:安装与图像采集测试

在Verybot上安装OpenCV是很简单的,只需要执行:         sudo apt-get update         sudo apt-get install libopencv-dev         sudo apt-get install python-opencv         下面就对安装好的OpenCV进行一下测试,编写一个通过USB摄像头采

BIRT 报表的自动化测试

来源:http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-birttest/如何为 BIRT 报表编写自动化测试用例 BIRT 是一项很受欢迎的报表制作工具,但目前对其的测试还是以人工测试为主。本文介绍了如何对 BIRT 报表进行自动化测试,以及在实际项目中的一些测试实践,从而提高了测试的效率和准确性 -------

可测试,可维护,可移植:上位机软件分层设计的重要性

互联网中,软件工程师岗位会分前端工程师,后端工程师。这是由于互联网软件规模庞大,从业人员众多。前后端分别根据各自需求发展不一样的技术栈。那么上位机软件呢?它规模小,通常一个人就能开发一个项目。它还有必要分前后端吗? 有必要。本文从三个方面论述。分别是可测试,可维护,可移植。 可测试 软件黑盒测试更普遍,但很难覆盖所有应用场景。于是有了接口测试、模块化测试以及单元测试。都是通过降低测试对象