写点什么

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

  • 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:422341
用户头像

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

关注

评论

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

MediaMuxer实用封装

Changing Lin

8月日更

极光开发者周刊【No.0730】

极光JIGUANG

Hudi自带工具DeltaStreamer的实时入湖最佳实践

华为云开发者联盟

大数据 Hudi

三面拼多多,一篇文章帮你解答

JVM调优资料

Java 程序员 后端

SpringBoot使用Junit5

Rubble

springboot JUnit 8月日更

Redis挂了,流量把数据库也打挂了,怎么办?

why技术

Java 面试

Ubuntu 与 Mac 共享文件

TroyLiu

ubuntu 效率 Mac 文件传输 共享文件

是谁,在暗中观察

skow

Java 后端 Java设计模式 8月日更

synchronized 加锁 this 和 class 的区别!

王磊

Java 并发 8月日更

中高级Java面试中你不得不会的知识点,附详细答案

JVM调优资料

Java 程序员 后端

肝到头秃!阿里爆款的顶配版Spring Security笔记

Java spring 程序员 架构 计算机

如何使用 DDD 指导微服务拆分?

架构精进之路

微服务 DDD 8月日更

【Jackson技术专题】全方位系统化学习和使用指南

洛神灬殇

Jackson JSON库 JSON序列化 8月日更

Apache ShardingSphere 元数据加载剖析

SphereEx

数据库 开源

五年Java开发者小米、阿里面经,附相关架构及资料

JVM调优资料

Java 程序员 后端

Java线程安全-JVM角度解析

程序员阿杜

Java JVM 多线程 并发 8月日更

硬核万字长文,深入理解 Java 字节码指令(建议收藏)

沉默王二

Java

中高级Java大厂高频面试题,已开源下载

JVM调优资料

Java 程序员 后端

MySQL不能没有字符串函数,就像西方不能失去耶路撒冷

北游学Java

Java MySQL 数据库

CIS Kubernetes 基线测试

greatersecurity

为什么@Value可以获取配置中心的值?年薪超过80万!

JVM调优资料

Java 程序员 后端

为什么spring能最好地改变Java?成功跳槽阿里!

JVM调优资料

Java 程序员 后端

京东面试真题解析,帮你解决95%以上的问题!

JVM调优资料

Java 程序员 后端

MySQL触发器介绍

Simon

MySQL

【Vue2.x 源码学习】第二十三篇 - 依赖收集 - 视图更新部分

Brave

源码 vue2 8月日更

图片风格迁移:基于实例缓解细节丢失、人脸风格化失败问题

华为云开发者联盟

神经网络 风格 实例 风格迁移 图像翻译

五面阿里拿下飞猪事业部offer,帮你突破瓶颈

JVM调优资料

Java 程序员 后端

中国首位 K8s ingress-nginx reviewer 同时提名成为 Apache APISIX committer

API7.ai 技术团队

开源 Kubernetes 采访 APISIX

【共识专栏】共识的分类(下)

趣链科技

区块链 共识机制 共识算法 共识分类

为什么大公司一定要使用微服务?神操作!

JVM调优资料

Java 程序员 后端

五分钟搞懂MySQL主从复制原理,附带学习经验

JVM调优资料

Java 程序员 后端

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