2天时间,聊今年最热的 Agent、上下文工程、AI 产品创新等话题。2025 年最后一场~ 了解详情
写点什么

从瀑布流到敏捷和 DevOps,测试该如何改变

  • 2015-11-17
  • 本文字数:2025 字

    阅读完需:约 7 分钟

Laurent Py 在 Hiptest 上发表了博客《向左走向右走:测试的摇摆》,其中描述了当研发模式从瀑布流到敏捷到随后的DevOps,会如何影响测试。在敏捷测试日2015(Agile Testing Days 2015),他以此做了演讲。

InfoQ 采访了 Laurent Py,了解他们转型到敏捷和 DevOps 的原因和从“测试摇摆”获取的益处;在测试自动化策略和实施方便,如何通过度量行为改变,来找出一个特性是否是有价值的;以及他预计测试将会带来的特性。

InfoQ**:在博客中,你探索了当研发模式从瀑布流到敏捷和现在的DevOps对于测试的改变。你能详细描述下为什么会做出这样的改变?**

Py:这主要因为反馈的速度和精益启动的实践。10 年前我的团队使用 Java 和 Eclipse 进行产品开发。我们每年做两次发布。这个流程的问题是反馈速度。在几个月里,我们开发和创建一个“资产”。但是由于它还没有交付到用户手上,这个资产的价值为 0。从商业角度来说,当每年只有 2 次机会,我们很难快速适应和转变。

因此,最初我们采用了敏捷,同时简化了流程。从工程师角度来看,这是非常有益的,因为我们每两周会出一个工作产品。但是由于这些产品无法立即部署到生产环境,我们同样有反馈速度的问题。用户不会希望没两周就安装一个发布版本。

现在,团队在云上开发新的产品,一个为敏捷团队使用的测试管理平台( hiptest.net )。开发和运维协同工作,并且开始持续部署。由此,我们不仅有了优秀的工程流程,而且最终我们能够从用户获取反馈并且实时做出响应。对我来说,这就是实施敏捷和 DevOps 而获得的最大收益。

InfoQ**:你从敏捷和DevOps中得到了什么收益?**

Py:开发出产品是其一;将产品交付给用户是另一方面。因此获取快速反馈的能力,确实提高了团队的参与度。作为一个团队成员,我们能够看见所做功能的影响,并且不用再像以前那样,需要花费几个月才能得到结果。从工程角度来讲,这是非常困难的,并且需要许多训练,但这显然是值得努力的。我相信最终只有一个结局:用户和客户。介于二者之前的其他结果都不能算是成功。

InfoQ:你能解释下你所说的**“测试摇摆”**的含义吗?

Py:“测试摇摆”我主要想表示向左走和向右走。以前,测试基本上都在开发阶段之后和产品上线之前完成。目前,部分测试活动已经向左移:测试在开发阶段之前设计。这就是行为驱动开发(Behavior Driven Development,BDD)的实践。这能够使得团队成员对他们的最终产品的定义理解相同。所有利益相关方(测试、开发、产品负责人、市场)协作于:

  • 产品验收标准:样本
  • 商业验收标准:待验证的假设

然后,我们需要向右走:测试(A/B 测试)和直接在产品中监控。重要的是,我们有一个实时用户反馈(通过实时聊天),以获取以前可能无法获取的问题。有的时候,错误的行为可能不是源于代码的错误,而仅仅是一个坏的用户体验或者数据达到一定量的时候才会出现。由于我们有快速的反馈,并且拥有持续部署的能力,我们能够在出现问题的时候快速反应。

InfoQ:在博客中,你提到了你在通过度量用户行为的改变,来判断一个新功能对于用户是否是有价值的。对此能否给一些示例,说明你是如何做到的?

Py我们在 Hiptest 中加入了测试重构功能。这是一个关键的区分点,我们可以度量有多少用户真的使用了这项功能。但是度量影响是更重要的。我们已经度量到了,使用这个新功能的用户,增强了自动化水平,同时增加了 Hiptest 的使用度。因此,当开发一个新功能,并且度量它的价值,不仅仅是询问“是否有用户在使用?”,而是关于对我们商业上的影响和对用户工作流程的影响。

InfoQ:对于测试自动化,你的策略和实践是怎么样的?

Py:每个测试用例都应该讲一个关于应用程序的故事。当一个测试用例使用一致的业务术语定义(行为驱动开发实践),它的可读性会比较高,且容易自动化。这也是 Hiptest 支持的哲学。顺便说一下,我们使用 Hiptest 来测试 Hiptest,并且使用我们的测试脚本实现 100% 的自动化。自动化部分通过图形用户界面实现,余下的直接使用 API。当然,自动化测试用例和持续集成结合。再次强调反馈速度对于开发者来说是非常关键的。当开发者提交代码时,他需要快速知道这些代码是否破坏了什么东西。

InfoQ:你期望未来测试领域会给我带来什么?

Py我希望测试会更加面向商业。一些人担心质量保证岗位会消失。我认为这是一个机会——如果能把握住的话。如果一个功能没有使用,或者没有给产品带来显著的价值,在功能正确性和性能上投入大量精力又有什么意思?这是测试人员的批判性思维能够发挥作用的时候。为什么我们要构建这个产品?我们构建这个产品的假设是什么?如果答案是肯定的,那么确保正确性才有意义。

查看英文原文: How Testing Changed When Moving from Waterfall to Agile and DevOps


感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。

2015-11-17 18:008057

评论

发布
暂无评论
发现更多内容

canvas

Jason199

canvas 8月月更

Kubernetes 维护技术分享

CTO技术共享

开源 签约计划第三季 8月月更

What's new in dubbo-go-pixiu 0.5.1

apache/dubbo-go

dubbogo Dubbo3 Dubbo网关

React Redux 组件更新/渲染原理 connect 中的 mapStateToProps

HullQin

CSS JavaScript html 前端 8月月更

一次由groovy引起的fullGC问题排查

转转技术团队

风控逻辑利器---规则引擎

转转技术团队

Java 规则引擎 风控 后端、 特征工程

API服务网关

阿泽🧸

API网关 8月月更

开源一夏|OpenHarmony如何选择图片在Image组件上显示(eTS)

坚果

开源 OpenHarmony 8月月更

Spring 全家桶之 Spring Data JPA(一)

小白

8月月更

ThreadLocal全面解析(一)

自然

ThreadLocal 8月月更

开源一夏 | 盘点 GitHub 那些标星超过 20 K 的 Golang 优质开源项目

宇宙之一粟

GitHub 开源 Go 语言 gopher 8月月更

【LeetCode】把二叉搜索树转换为累加树Java题解

Albert

LeetCode 8月月更

RocketMQ整体架构与基本概念

急需上岸的小谢

8月月更

超大模型工程化实践打磨,百度智能云发布云原生 AI 2.0 方案

Baidu AICLOUD

资源调度 异构计算 AI加速 GPU容器虚拟化 云原生AI

《DevOps围炉夜话》- Pilot - CNCF开源DevOps项目DevStream简介 - feat. PMC成员胡涛

玩转Devop和研发效能DevStream/DevLake

开源 DevOps cncf WLB

Kubernetes 选举机制HA

CTO技术共享

开源 签约计划第三季 8月月更

Java System.lineSeparator 方法

HoneyMoose

元宇宙社交应用,靠什么吸引用户「为爱发电」?

融云 RongCloud

元宇宙

Kubernetes 计算CPU 使用率

CTO技术共享

开源 签约计划第三季 8月月更

开源一夏 | 参与开源能让人更幸福

石云升

开源 开源社区 8月月更

鲲鹏编译调试及原生开发工具基础知识

乌龟哥哥

8月月更

参天生长大模型:昇腾AI如何强壮模型开发与创新之根?

脑极体

2022-Java后端工程师面试指南-(计算机网络)

自然

网络 watt network 8月月更

云服务器基于 SSH 协议实现免密登录

昆吾kw

Linux SSH 云服务器

IFIT的架构与功能

穿过生命散发芬芳

8月月更 IFIT

10道不得不会的Docker面试题

JavaPub

redis Docker

Kubernetes你不知道的事

CTO技术共享

开源 签约计划第三季 8月月更

MySQL高级指令

武师叔

8月月更

学习Apache ShardingSphere解析器源码(一)

我不吃六安茶

ANTLR Apache ShardingSphere

Thread State 详解

自然

Thread 8月月更

从瀑布流到敏捷和DevOps,测试该如何改变_软件工程_Ben Linders_InfoQ精选文章