写点什么

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

评论

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

架构误区系列12:一切皆依赖云平台

agnostic

云计算 部署架构

工作这么多年,我总结的数据传输对象 (DTO) 的最佳实践

JAVA旭阳

Java 架构

【PHP】英文博客专栏PHP快速入门个人笔记

懒时小窝

php

我们需要怎样的低代码平台

agnostic

低代码

【Linux技术专题系列】「必备基础知识」一起探索和实践sftp配置之密钥方式登录

码界西柚

Linux SSH SSH工具 sftp

关于环境变量配置的思考总结

timerring

Go 环境变量

开源移动核心网Magma架构设计启示

俞凡

架构 网络 通信

如何快速优雅的用Know Streaming创建Topic

石臻臻的杂货铺

获取 topic等信息 后端、

精华推荐 | 【JVM深层系列】「GC底层调优系列」一文带你彻底加强夯实底层原理之GC垃圾回收技术的分析指南(GC原理透析)

码界西柚

Java JVM JVM原理 2023

复习前端:前端应掌握的网络知识

devpoint

OSI七层协议 http2 HTTPS协议加密

2022年终总结-无所吊谓

wood

年终总结 稳定 开心 普通的一年

Studio One2024旗舰级DAW的跨版本升级

茶色酒

Studio One 5 Studio One2023

极客时间运维进阶训练营第十二周作业

9527

CleanMyMacX4.12.2最新版本更新下载

茶色酒

CleanMyMacX

水果软件2024FL Studio中文语言版本下载

茶色酒

FL Studio FL Studio 21

万字长文搞懂产品模式和项目模式

俞凡

团队管理

Portraiture2024汉化版磨皮插件下载

茶色酒

Portraiture2023 Portraiture

Kratos微服务框架API工程化指南

golang gRPC microservice Kratos 工程化

你知道哈希算法,但你知道一致性哈希吗?

JAVA旭阳

Java 架构

JSON.stringify() 的 5 使用场景

devpoint

JavaScript 前端开发 JSON格式化

FPGA:硬件描述语言简介

timerring

FPGA

会声会影2023和谐版本补丁包下载

茶色酒

会声会影 会声会影2023

复习前端:前端安全

devpoint

CSRF xss攻击 前端安全

复习前端:JavaScript V8 引擎机制

devpoint

chrome JIT V8

Python 内置界面开发框架 Tkinter入门篇 甲

eng八戒

Python GUI tkinter

CleanMyMac X2024汉化版安装包新增

茶色酒

CleanMyMac X CleanMyMac X2023

从任务分配角度来看管理

石云升

极客时间 1月月更 技术领导力实战笔记

技术如何分担产品之忧?

石云升

极客时间 1月月更 技术领导力实战笔记

技术管理者如何获得下属的认同?

石云升

极客时间 1月月更 技术领导力实战笔记

【Redis技术专区】「优化案例」谈谈使用Redis慢查询日志以及Redis慢查询分析指南

码界西柚

redis 性能调优 慢查询

架构误区系列11:无聊的架构归一

agnostic

架构治理

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