AICon上海|与字节、阿里、腾讯等企业共同探索Agent 时代的落地应用 了解详情
写点什么

敏捷测试工程师的十条法则

  • 2010-11-11
  • 本文字数:2189 字

    阅读完需:约 7 分钟

对于初涉敏捷的测试工程师来说,如果定位自己的角色和职责、如何从传统开发模式成功迁移到敏捷模式、如何跟上短迭代的节奏等等问题都迫切地想要找到答案。 资深敏捷实践者 Lisa Crispin 和 Janet Gregory 在《敏捷软件测试:测试人员与敏捷团队的实践指南》一书中,列举了敏捷测试工程师的十条法则,对读者或许有借鉴意义。

  • 提供持续反馈(Provide Continuous Feedback)

既然是测试驱动敏捷项目,那么很显然反馈在敏捷团队中占据重要的地位。测试人员的传统角色就是“信息提供者”,这使得她天生就对敏捷团队很有价值。敏捷测试人员的最大贡献之一是帮助产品负责人或者客户采用实例和测试的形式描述清楚每一个用户故事的需求。然后,测试人员与团队同事将这些需求转化为可执行的测试。测试人员、开发人员和其他团队成员尽快运行这些测试,并不断接收有意义的反馈。

  • 为用户创造价值(Deliver Value to the Customer)

敏捷开发就是在较小的版本发布中提供客户目前最迫切需要的功能。这通常意味着限定范围。我们经常在客户团队中遇到较酷功能的需求。任何人都可以质疑这些内容,但是测试人员会判断其对故事的影响,因为他们需要考虑测试后果。 敏捷测试人员需要总览全局。我们可以在当前迭代中发布最重要的功能,稍后再完善。如果让新功能偷偷混进来,就面临一无所获的风险。如果过于关注边边角角,而忽略了核心功能,就无法提供业务所需的价值。

  • 促进面对面的沟通(Enable Face-to-Face Communication)

敏捷测试人员从客户的角度思考每一个故事,但是也理解实现功能相关的技术和局限性。他们可以帮助客户和开发人员达成共识。业务人员和软件人员经常使用不同的语言。他们不得不找到一些共同点来协作。测试人员可以帮助他们达成一种共通语言。 面对面的沟通是不可替代的。敏捷开发依赖于持续的合作。就像其他敏捷团队成员一样,从事测试工作的人会不断寻找客户和技术团队成员来讨论和合作。当敏捷测试人员对某个隐藏的假设或者误解的需求产生怀疑时,她会与客户和开发人员讨论。如果处于不同地点的人需要交谈,他们会试图寻找创造性的方式替代面对面、实时的交流。

  • 勇气(Have Courage)

当最初加入敏捷团队或者当前的团队开始过渡到敏捷开发模式时,通常会产生恐惧感,并且存在大量的问题需要答案。我们到底如何才能在如此短的时间内完成每一个用户故事的测试任务?测试如何跟上开发的节奏?如何确定多少测试就够了?又或者你是功能测试经理或者质量过程经理,不清楚在敏捷团队中如何定位自己的角色,没人知道答案。敏捷测试人员需要勇气找到这些问题的答案,但是除此之外还有其他原因。我们需要勇气允许自己失败,至少我们会短暂失败,并从中学习教训。在由于构建版本不稳定导致一次迭代失败之后,我们开始寻找方法以确保这种事情不再发生。

  • 简单化(Keep It Simple)

简单并不意味着容易。对于测试人员来说,这意味着采用能够找到的最轻量级的工具和技术恰到好处地测试。工具可以简单到只是一张电子表格或者清单。需要自动化回归测试,但是应该把它们分解到最底层以获取快速反馈。甚至简单的冒烟测试也可能满足面向业务的测试自动化。

  • 持续改进(Practice Continuous Improvement)

想办法把工作做得更出色是敏捷测试人员思想的一部分。当然,整个团队都应该具有这样的想法,因为敏捷的核心价值就是团队总是尝试更出色地工作。测试人员参加团队总结会,评估做得好的方面和需要增加和改变的方面。测试人员把测试问题摆到整个团队中解决。团队通过采取过程改进实践最大程度地改善测试和所有其他领域。对于更大的问题,团队一次只关注一到两个问题,以确保彻底解决了实际问题,而不是表面文章。

  • 响应变化(Respond to Change)

响应变化是敏捷实践的重要价值,但是我们发现这对测试人员来说却是最困难的概念之一。测试人员渴望的是稳定,所以他们会说:“我已经测试过了,任务完成了”。持续的需求变化是测试人员的噩梦。但是,作为一名敏捷测试人员,我们不得不拥抱变化。周三,我们可能期望启动故事 A 和 B,下周五做 C。但是到了周五,客户重新设定了优先级,现在需要故事 A、X 和 Y。只要我们持续与客户交流,就能处理这些变化,因为我们与团队的其他成员保持同步。

  • 自我组织(Self-Organize)

敏捷测试人员是自组织敏捷团队的组成部分。团队文化贯彻于敏捷测试理念。当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试自动化,测试人员就会获得全新的视角。自动化测试很困难,但是当整个团队都在为此努力时就会简单得多。当大家具有多重技能和多层次视角时,任何测试问题都更容易解决。

  • 关注人(Focus on People)

坚持敏捷理念的敏捷团队对所有团队成员一视同仁。敏捷测试人员对团队做出了特有的贡献,开发团队认识到要想更加成功,团队需要拥有测试技能和背景的人。举例来说,一位熟练的探索性测试人员可能会发现自动化功能测试无法察觉的问题。一些测试经验丰富的工程师会提出其他人想不到的重要问题。测试知识是任何一个成功团队的组成部分。

  • 享受乐趣(Enjoy)

在我们看来,测试人员的理想团队是:所有成员协作,从项目的开始一直到结束,利益相关者与开发团队共同工作,整个团队负责质量和测试。相信很多人都认为每个人都应该在工作中找到乐趣。敏捷开发珍视敏捷测试人员对工作的激情。

众所周知,敏捷软件测试工作不是一件轻松的事情,读者在敏捷软件测试实践中存在哪些优秀的经验,欢迎分享。

2010-11-11 23:422486
用户头像

发布了 501 篇内容, 共 266.4 次阅读, 收获喜欢 61 次。

关注

评论

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

django-task1 笔记之python基础

橙橙橙橙汁丶

django #python

Java中的关键字final

架构精进之路

Java 6月日更

《转》HttpURLConnection自动重试机制

hasWhere

相比买买买,我们更想在618聊一聊云厂商的能力象限价值几何

脑极体

一个jvm线程占用多少操作系统内存

hasWhere

星环科技TDH8.0使用必读2: 10种数据模型全支持 未来属于多模型大数据平台

星环科技

大数据 边缘计算 知识图谱 数据管理平台 多模型数据

ios webRTC实现屏幕共享功能

侠客行

ios WebRTC iOS屏幕共享 replaykit

5分钟速读之Rust权威指南(二十三)Cargo

wzx

rust

《原则》(十六)

Changing Lin

6月日更

form-data和x-www-form-urlencoded

hasWhere

Tomcat架构的认知

邱学喆

tomcat @WebServlet @WebFilter Manager

百度智能云NIRO MAX机器人,打造智慧党建新体验!

百度大脑

人工智能 百度 机器人

MySQL基础之十四:事务

打工人!

MySQL 6月日更

DeFi从入门到精通

hasWhere

戏说前端 JavaScript 之『防抖节流』基础知识

编程三昧

JavaScript 大前端 防抖节流 函数节流 函数防抖

【21-9】文件和文件夹

耳东@Erdong

PowerShell 6月日更

2021年5月云主机性能评测报告出炉,华为云跃居榜首

博睿数据

云主机 博睿数据 博睿指数

源码级别理解 Redis 持久化

蘑菇睡不着

Java redis Redis 协议

沟通的方法:反向叙述

石云升

读书笔记 沟通 6月日更

16倍效率提升体验,博睿数据APM成企业运维超级加速器

博睿数据

APM 博睿数据 数据链DNA

一体化、标准化、可视化数据平台,博睿数据领跑智能运维新典范

博睿数据

博睿数据 数据链DNA dataview

Kubernetes手记(13)- 用户认证系统

雪雷

k8s 6月日更

Zookeeper在线迁移

阿骆麦迪

zookeeper 分布式 中间件 6月日更

BoCloud博云稳居中国容器软件市场份额TOP 5

BoCloud博云

容器

数字化转型须遵循“战略五原则”和“3-1-1战术”

李洋

数字化转型 信创 战略思考 企业数字化 战略技术

科普 DeFi 中的闪电贷

hasWhere

servlet工作原理之tomcat篇

hasWhere

C#开发之基于NPOI的操作Excel开发体验

吴脑的键客

C# Excel

内推学弟进了腾讯,看看他的标杆简历!

程序员鱼皮

Java 后端 简历 校招 秋招

数据库索引为什么使用B+树

hasWhere

互联网推送服务原理

hasWhere

敏捷测试工程师的十条法则_研发效能_崔康_InfoQ精选文章