写点什么

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

评论

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

Java源码系列3——LinkedHashMap

超超不会飞

Java

在 InfoQ 兼职做运营

邓瑞恒Ryan

创业 用户增长 创业心态 运营 产品运营

用go语言实现快排

Sean

算法 快速排序 Go 语言

高中生写LOL外挂1年狂赚五百万,落网前刚买下120万保时捷

Java架构师迁哥

【架构笔记之设计模式】架构师训练营第1期第3周

业哥

极客大学架构师训练营

架构师训练营第1期第3周作业

业哥

极客大学架构师训练营

优秀组织的5大表现

凌晞

团队管理 团队组织 组织

FastDFS 分布式文件系统详解

哈喽沃德先生

文件系统 分布式文件存储 fastdfs 分布式文件

Nexmark: 如何设计一个流计算基准测试?

Apache Flink

flink

传统网络缺失货币层,比特币是否能担此大任?

blockchain

比特币 区块链 数字货币 比特币数字货币 区块俩金融

智能体的奇幻漂流之“成都折叠”篇

脑极体

2020互联网公司中秋礼盒大比拼!(文末送福利)

Java架构师迁哥

架构师训练营第 1 期第 3 周学习总结

好吃不贵

极客大学架构师训练营

一个好系统自我完善自我进化的方法

boshi

产品思维 系统工程 即时反馈 生态体系

Smartisan

Changing Lin

摄影

Dromara团队发布Hmily全新架构的2.1.1版本

猫大人

分布式事务 分布式柔性事务‘’

我一定是熬夜熬傻了,小程序后台获取用户信息居然发生了这件事

小Q

Java 小程序 学习 编程 架构

一个Hibernate的事务问题

YoungZY

hibernate

【FastDFS】SpringBoot整合FastDFS实战,我只看这一篇!!

冰河

springboot fastdfs

码住!Flink Contributor 速成指南

Apache Flink

flink 开源社区

Greenplum 性能优化之路 --(二)存储格式

腾讯云大数据

大数据

鲲鹏播种于时代,花开五色中原

脑极体

架构师训练营第三周作业

邓昀垚

极客大学架构师训练营

Greenplum 性能优化之路 --(三)ANALYZE

腾讯云大数据

大数据 数据仓库

c++杂谈4

菜鸟小sailor 🐕

Java源码系列2——HashMap

超超不会飞

Java

Java源码系列4——HashMap扩容时究竟对链表和红黑树做了什么?

超超不会飞

Java

烦人的Null,你可以走开点了

四猿外

Java 注解 空指针 Optional null

基于 Flink + Hive 构建流批一体准实时数仓

Apache Flink

flink

经常使用的数据结构

hasWhere

CSS语法与规则 — 重学CSS

三钻

CSS 大前端

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