写点什么

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

评论

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

助力人工智能教育普及 宾果智能机器人走进全国千所小学

硬科技星球

GPT大语言模型引爆强化学习与语言生成模型的热潮、带你了解RLHF。

汀丶人工智能

强化学习 ChatGPT AI大语言模型

Prompt-“设计提示模板:用更少数据实现预训练模型的卓越表现,助力Few-Shot和Zero-Shot任务”

汀丶人工智能

人工智能 Prompt prompt 工程

开源Java诊断工具Arthas:开篇之watch实战

javalover123

Java 开源 Arthas watch 诊断

ARTS打卡第一周

苏籍

技术 ARTS 打卡计划 #成长经验

如何使用LLM实现文本自动生成视频

3D建模设计

Python 人工智能

如何使用Redis实现分布式锁?

王磊

Java Java面试题

文心一言 VS 讯飞星火 VS chatgpt (79)-- 算法导论7.4 4题

福大大架构师每日一题

福大大架构师每日一题

使用 Terraform 与事件驱动的 Amazon CodeBuild 提升云上数据应用运维效率

亚马逊云科技 (Amazon Web Services)

云原生

【ARTS】Week 1

小小

ARTS 打卡计划

企业级私有化部署即时通讯,完美替代SaaS平台

BeeWorks

为什么Nop平台坚持使用XML而不是JSON或者YAML

canonical

json xml 低代码 Nop平台

LangChain + Streamlit + Llama:将对话式AI引入本地机器

3D建模设计

人工智能 LLM

2023 ARTS 打卡第一周

Z.

ARTS 打卡计划

ARTS 打卡第 1 周

orient

ARTS 打卡计划

ARTS 打卡第 12 天

自由

ARTS 打卡计划

从来不懂K8s的人在10分钟内将应用跑在了K8s中

北京好雨科技有限公司

Kubernetes 开发者 云原生 应用部署

华为云开发工具CodeArts IDE for C/C++ 开发使用指南

ide 开发工具 华为云 开发环境

使用 ChatGPT 的代码解释器进行数据科学的 5 种方法

3D建模设计

Python 数据分析 ChatGPT

领域驱动设计(DDD):从基础代码探讨高内聚低耦合的演进

付威

架构 领域驱动设计 DDD

企业级即时通讯协作和移动应用管理平台哪个品牌好?

BeeWorks

近期大型攻防演练观感及未来攻防趋势判断

墨菲安全

安全 软件供应链

C++的对象与类的含义

芯动大师

ARTS 打卡第 1 周

AI帅辉

ARTS 打卡计划

ARTS打卡Week1

JimDeng

ARTS 打卡计划 go modules

学习 ChatGPT 一切基础知识的绝佳资源

3D建模设计

人工智能 ChatGPT LLM

2023 ARTS打卡第一周

犇犇

ARTS 打卡计划

一个炫酷的头像悬停效果 2

南城FE

CSS 前端 动画 SASS 交互

Programming abstractions in C阅读笔记:p123-p126

codists

Presto 设计与实现(六):JMX

冰心的小屋

数据湖 JMX presto presto 设计与实现

一云多芯能力再获认可!天翼云助推政企上云行稳致远!

天翼云开发者社区

云计算

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