QCon 演讲火热征集中,快来分享技术实践与洞见! 了解详情
写点什么

从瀑布流到敏捷和 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:007673

评论

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

YashanDB V22.2重磅发布!七大亮点带你了解新特性

YashanDB

数据库

nvim 配置c++环境

linux大本营

vim C++

dpdk中,如何建立portid/queue的配置和逻辑核心的关系

linux大本营

队列 DPDK DPDK开发

openbmc 中如何使用D-bus

linux大本营

dbus openBMC

6G 通信技术和 5G 通信技术的区别

汪子熙

通讯协议 通讯 三周年连更

云BI产品瓴羊Quick BI,为企业数字化转型保驾护航

巷子

解析下rte_pktmbuf_pool_create参数含义

linux大本营

DPDK DPDK开发

重载++运算符分别实现i++和++i

linux大本营

运算符 数据结构与算法

linux dbus客户端和服务器示例代码

linux大本营

c++ Linux dbus

打工人逃不开「单人单岗」

Java 架构 程序人生 职场

UDP报头是通过结构体位段实现的吗

linux大本营

网络协议 udp UDP协议

dpdk l2fwd如何初始化每个逻辑核的port/queue的

linux大本营

队列 DPDK DPDK开发

扎最深的寨,打最持久的仗——一知智能AI商业化攻略访谈录

B Impact

电子签赛道驶向深水区,法大大以数智化引领创新

ToB行业头条

来字节跳动实习,有机会发Nature子刊

字节跳动技术范儿

第五期(2022-2023)传统行业云原生技术落地调研报告——金融篇

York

容器 DevOps 微服务 云原生 金融

写一个完整的SHOW TABLE STATUS 语句返回的所有表的状态信息对应的结构体

linux大本营

数据库 存储 结构体 C++

共话数字化新技术、新趋势 华为云开发者日东莞站成功举办

Geek_2d6073

linux dbus代码举例

linux大本营

Linux C++

eBPF的发展演进---从石器时代到成为神(三)

统信软件

操作系统 Linux内核

什么是文件传输,介绍文件传输的发展进程

镭速

对数据库中存储的程序进行现代化改造,以使用 Amazon Aurora PostgreSQL 联合查询、pg_cron 和 Amazon Lambda

亚马逊云科技 (Amazon Web Services)

一个有趣的图片加载效果

南城FE

CSS 前端 动画 图片

如何使用 SCP 和 Rsync 在 Linux 中传输文件

wljslmz

Linux 三周年连更

什么是Java 异常?如何处理异常?

Java架构历程

Java 三周年连更

Django笔记十七之group by 分组用法总结

Hunter熊

Python django count 分组查询 sum

一文带你了解实战常用JavaScript API

程序员海军

JavaScript 三周年连更

数说热点|米哈游新作《崩坏:星穹铁道》今日公测,能否再现原神奇迹?

MobTech袤博科技

重磅!阿里云云原生合作伙伴计划全新升级:加码核心权益,与伙伴共赢新未来

阿里巴巴云原生

阿里云 云原生 生态合作

容量成本性能全都要有, Redis 容量版 PegaDB 设计与实践

百度开发者中心

云数据库 百度智能云

Go sync.Once:简约而不简单的并发利器

陈明勇

Go golang 高并发 三周年连更 sync.Once

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