QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

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

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

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

关注

评论

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

Linux设备驱动系列(十)——等待队列Waitqueue

Linux内核拾遗

队列 Linux内核 设备驱动

null是原始类型,但为什么typeof null的结果是object?

Geek_fed966

Required request parameter ‘XXX‘ for method parameter type String is not present

源字节1号

开源 软件开发 前端开发 后端开发 小程序开发

事业-最佳实践-编码-声明规范

南山

大模型探索:阿里向量检索服务DashVector

程序员架构进阶

架构 向量检索 大模型 5月月更 通义千问

劳动节,聊聊AI究竟在替代谁的工作?

脑极体

AI

2024年4月文章一览

codists

编程人

1/28 业务系统的安全设计

hackstoic

系统设计 安全 TGO写作小组28天挑战

前端面试题 - 如何实现promise?

Geek_fed966

事业-最佳实践-编码-异常处理规范

南山

异常 异常处理

事业-最佳实践-编码-注释规范

南山

代码注释 注释 添加注释 注释规范

事业-最佳实践-编码-CR认知

南山

CR CodeReview

2024-05-01:用go语言,给定两个长度为偶数n的整数数组nums1和nums2, 分别移除它们各自的一半元素, 将剩下的元素合并成集合s。 找出集合s中可能包含的最多元素数量。 输入:nums

福大大架构师每日一题

福大大架构师每日一题

OceanBase开发者大会·2024精彩PPT合集

菜根老谭

oceanbase

淘宝商品详情API接口:实时获取SKU价格及库存信息

技术冰糖葫芦

API Explorer API boy pinduoduo API

开源框架 NanUI 项目宣布将暂停开发,作者转行卖钢材

源字节1号

开源 软件开发 前端开发 后端开发 小程序开发

AI 如何赋能优质直播内容创作?

自象限

2/28 业务系统高可用设计(上)

hackstoic

架构设计 TGO写作小组28天挑战

《自动机理论、语言和计算导论》阅读笔记:p215-p351

codists

编译原理

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