自动化check是不是测试?

这篇文章是reddit上关于质量保障讨论的比较多的帖子,我把它转为中文版,供大家交流学习,由于直接用的翻译软件以及截图,大家凑合看下哈。

自动化检查并不是真正的"测试"?编写自动化检查确实很重要------但编写自动化测试代码和框架与成为"软件测试/质量专家"是完全不同的两回事。我们应该停止称其为"自动化测试",而应称之为"自动化检查"。

因为这种"如果我们自动化一切,那就没问题"的想法,导致了20亿美元的Crowdstrike漏洞以及其他许多对纳税人造成巨大损失的情况。不,这并不正确。实际的测试需要人类的参与。如果没有人类参与,那就不是测试。因为自动化工具太笨了,无法发现哪里出了问题,因为它只被设计用来检查几件事情。至少目前,没有人能用工具的自动化检查来替代人类的认知能力。

正如软件测试行业专家迈克尔·博尔顿所说

"测试是通过经验、探索和实验来评估产品的过程。这包括一定程度上的提问、研究、建模、观察、推断等,目的是发现产品的真实状态或系统。"

测试人员不会看到令人赏心悦目的演示就大声叫好"太棒了,太棒了!" 当我们周围的每个人都被炫目的效果、分散的注意力和坚定的"一切都很好"所迷惑时,测试人员必须在专业上持怀疑态度。在我们看来,测试是从一个前提开始的:产品中存在其他人没有注意到的问题风险,因为"项目中的其他人都没有把调查潜在问题作为自己的主要职责"。

这就是为什么在项目和组织中拥有经过培训、能够像测试人员一样思考的人员非常重要的原因。如果你不专注于寻找问题,那么问题就会乐意来找你......或者你的客户。

是时候让组织机构认识到这一点了,不要再把管道中的愚蠢的绿色自动化检查作为释放软件的信号了。更有趣的是,有人认为API测试足以证明软件质量。这真是太可笑了,太愚蠢了。API测试的好坏取决于编写和确保合同更新等工作的人员。除了API返回正确值之外,还有1000种可能出错的情况。

你有没有听说过汽车制造商解雇质量部门,只依赖自动化检查来保证产品质量的情况?有趣的是,有些零售公司有专门的质量部门来检查硬件产品,但在零售软件开发方面,他们却只依赖Jenkins管道来保证质量。真是疯了!如果你不投资于质量,那么开发者将不得不花费更多的时间来修复bug,从而导致客户满意度下降甚至失去客户。

相关推荐
七夜zippoe11 小时前
CANN Runtime任务描述序列化与持久化源码深度解码
大数据·运维·服务器·cann
Fcy64812 小时前
Linux下 进程(一)(冯诺依曼体系、操作系统、进程基本概念与基本操作)
linux·运维·服务器·进程
袁袁袁袁满12 小时前
Linux怎么查看最新下载的文件
linux·运维·服务器
代码游侠12 小时前
学习笔记——设备树基础
linux·运维·开发语言·单片机·算法
Harvey90313 小时前
通过 Helm 部署 Nginx 应用的完整标准化步骤
linux·运维·nginx·k8s
珠海西格电力科技14 小时前
微电网能量平衡理论的实现条件在不同场景下有哪些差异?
运维·服务器·网络·人工智能·云计算·智慧城市
释怀不想释怀14 小时前
Linux环境变量
linux·运维·服务器
zzzsde14 小时前
【Linux】进程(4):进程优先级&&调度队列
linux·运维·服务器
聆风吟º16 小时前
CANN开源项目实战指南:使用oam-tools构建自动化故障诊断与运维可观测性体系
运维·开源·自动化·cann
NPE~16 小时前
自动化工具Drissonpage 保姆级教程(含xpath语法)
运维·后端·爬虫·自动化·网络爬虫·xpath·浏览器自动化