发布在即!企业 AIGC 应用程度测评,3 步定制专属评估报告。抢首批测评权益>>> 了解详情
写点什么

敏捷软件测试的七个关键成功要素​

  • 2011-07-09
  • 本文字数:4967 字

    阅读完需:约 16 分钟

资深敏捷专家 Lisa Crispin 在最近的讲座和参与合著的《 Agile Testing – A Practical Guide for Testers and Agile Teams 》中分享了敏捷软件测试的七个关键成功要素,包括​使用团队整体参与的方法、采用敏捷测试思维、​自动化回归测试、提供并获取反馈、构建核心实践的基础、与客户合作、保持大局观等。

使用团队整体参与的方法

当整个开发团队负责测试和质量问题,你会拥有很多不同的技能集合和经验等级来处理测试可能发生的问题。测试自动化对于技能高超的开发人员来说不是大问题。当测试置于团队的优先权,任何人都参与测试任务,团队才会设计可测试的代码。

使测试人员真正成为开发团队的一部分意味着向他们提供支持和训练他们适应敏捷开发的快节奏。他们需要时间掌握新技能以便与开发和客户团队紧密协作。

如果你管理一个敏捷团队,帮助团队使用团队整体参与的方法。记住质量,而不是速度,才是敏捷开发的目的。团队需要测试人员帮助客户理清需求,转化为指导开发的测试,提供发布优秀产品的唯一观点。确保测试人员能够把技能和长处转移到团队其他成员身上。确保他们不是局限于一种角色,如只做手动测试。确保当他们需要帮助时(可能需要极大的勇气),团队成员能够提供。反过来也是如此。测试人员应该随时准备帮助那些需要他们帮助的队友。

如果你是敏捷团队中的测试人员,并且计划会议和设计讨论没有邀请你,或者业务用户正在独自定义故事和需求,那你应该站出来和团队的其他成员交流。和开发人员一起参与会议,并提议尝试“三方协作”,即测试人员、开发人员和业务专家。谨慎地提供反馈并帮助客户提供例子。让你的问题成为团队的问题,让他们的问题成为你的问题。请你的同事采用团队整体参与的方法。

采用敏捷测试思维

我们提醒敏捷测试人员丢掉一直以来的“质量警察”思维。现在你在敏捷团队中,开发人员参与测试,测试人员可以做任何事情以帮助团队生产最优秀的产品。敏捷测试态度是前瞻性的、创造性的、欢迎新思想、乐于承担任何任务。敏捷测试人员不断磨练自己的技能,随时准备协作,相信直觉,希望帮助团队和业务成功。

我们并不是说你应该披上超级测试王的斗篷,去保护世界免受缺陷的危害。在敏捷团队中不存在狂妄自大。团队成员分享你对质量的追求。关注团队目标,帮助每一个更好地工作。

使用敏捷准则和价值观指导你。不断尝试最简单的方法来满足测试需要。勇敢地寻求帮助和实验新想法。关注于产生价值。尽可能多的直接交流。灵活地应对变化。记住敏捷开发以人为中心,我们应该享受工作。当对此怀疑时,回顾敏捷价值和准则来决定该怎么做。

敏捷测试思维的一个重要部分是不断想办法改进工作。成功的敏捷测试人员持续地磨练技能。读好书、博客和文章以获得新想法和技能。参加本地的用户组会议。加入邮件列表讨论以获得问题或者新想法的反馈。如果你的公司没有付钱让你参加一个很好的会议,那么把你的经验写成报告在免费的会上作交换。对测试和敏捷开发社区进行反馈也会对你有益。

实验新的实践、工具和技术。鼓励团队尝试新方法。短期迭代非常适合这种实验。你可能会失败,但是很快你可以尝试其他的。

如果你管理敏捷测试人员或者敏捷团队,给他们时间去学习并提供所需的培训支持。移除障碍使他们更好地工作。

当你面对影响测试的问题时,让团队都知道这些问题。通过头脑风暴的方式克服这些障碍。回顾会议可以讨论这些问题并想办法解决。维护一个阻碍事项列表,并在每个迭代中解决一到两个。使用可视化的大图片或者虚拟方式,确保所有人都知道发生的问题并可以跟踪编码和测试的进度。

自动化回归测试

敏捷团队没有测试自动化会成功吗?可能吧,但是我们所知道的成功团队都依赖自动化回归测试。如果你花费全部时间用在手动回归测试上,绝没有时间用于重要的探索性测试(会发现隐藏在代码中的危险行为)。

敏捷开发利用测试来指导开发。为了编写代码使测试通过,你需要快速、简单地运行测试。没有短期反馈周期和安全的回归测试,团队将很快陷入技术债务,缺陷不断增加,速度越来越慢。

自动化回归测试是团队的工作。整个团队应该选择每种测试适合的工具。提前考虑测试将帮助开发人员为了便于测试自动化来设计代码。使用敏捷测试象限和测试自动化金字塔来帮助你自动化各种类型的测试。

记住从简单入手。你会惊讶地发现一些基本的自动化冒烟测试或者自动化单元测试会发生很大作用。

测试自动化是团队的工作。开始时很艰苦,需要克服很大的痛苦。如果你管理开发或者测试团队,确保在时间、培训和激励上提供了足够的支持。如果你是没有自动化测试的团队的测试人员,开发人员疯狂地编写代码以至于不会停下来考虑测试,那么你会面临很大的挑战。尝试从管理层和团队成员中获取支持以开始小规模的自动化工作。

提供并获取反馈

反馈是敏捷的核心价值。敏捷的短期迭代可以提供持续的反馈以帮助团队运转正常。测试人员通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供反馈。

敏捷方法允许团队获取有关构建中软件的反馈。这是关键。故事代表了测试人员和分析人员向开发人员提供反馈的工作单元。迭代发布有助于团队外部的反馈。大多数敏捷实践都创建了反馈循环使团队应用。

测试人员也需要反馈。你怎么知道从客户手里拿到了预期行为的正确例子?你怎么知道编写的测试用例正确地反映了这些例子?开发人员通过查看你收集的例子和你创建的测试能够理解应该编写什么代码吗?

一个最有价值的技能是学习如何寻求自己工作的反馈。询问开发人员是否得到了足够的信息以理解需求并且是否能够指导编码。询问客户是否理解质量标准。花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。

构建核心实践的基础

  • 持续集成

每一个开发团队都需要代码管理和持续集成。如果不知道自己在测什么,就无法有效地测试,如果无法配置代码你根本无法测试。所有团队成员需要至少每天一次导入自己的工作。每一次集成必须通过自动化构建验证,其中包括提供软件状态快速反馈的测试。

实现持续集成过程应该是软件开发团队中优先级最高的事情。如果团队没有每日构建验证的版本,停止手里的工作,开始构建。就是这么重要。一开始并不要求太高。如果你有很大的系统需要集成,肯定会更具挑战性。通常来说没有那么困难,市面上存在很多优秀的工具,开源的、商业的。

  • 测试环境

没有可控的测试环境就无法有效地测试。你需要知道部署了什么版本,使用的数据库模式是什么,其他人是不是正在更新,其他进程是否运行在那台机器上。

硬件总是越来越便宜,开源软件越来越多。团队必须投资以有效地执行自动化和手动探索性测试。如果测试环境出现问题,赶紧说出来,让全队一起解决。

  • 管理技术债务

即使优秀的软件开发团队在感觉到时间压力之后,也会忽视重构或者快速解决问题修补缺陷。随着代码越来越混乱和难以维护,更多的缺陷出现,很快团队的速度就慢了下来,因为要解决缺陷才能添加新的功能。团队必须不断地评估技术债务的数量,并努力减少和避免。

大家经常说:“我们的管理层不会给我们时间做这些,没有时间重构,日程很紧”。但是,我们可以很容易举一个业务用例来显示增长的技术债务如何耗费公司的成本。衡量代码和缺陷率哪些会导致技术负债变为对底线的影响存在很多办法。仅仅指出不断下降的速度就足够了。业务需要软件开发团队保持持续的生产力。他们不得不减少期望功能的范围以保证足够的时间来进行良好的、测试规范的代码设计和优秀实践,如持续小规模重构。

自动化回归测试的良好覆盖率是最小化技术债务的关键。如果缺少,那就在每个迭代中拿出时间来构建自动化测试,规划一个“重构迭代”以升级或添加必要的工具,编写测试并进行重构。在每个迭代中花时间通过测试指导代码,重构必要的代码,添加丢失的自动化测试。对这件工作要重视。长期来看,团队能够变得更快。

  • 增量工作

敏捷团队能够生产高质量代码的一个原因是他们小规模地工作。故事代表了几天的工作量,每个故事被分解成小增量,按步构建。测试可以针对一小块,并且随着功能聚集再增量测试。

如果团队成员喜欢一次开发一大块功能,鼓励他们采用步骤式的方法。提出问题:“这个故事的核心业务价值是什么?这块代码的最基本路径是什么?下一步干什么?”建议大家编写任务卡片以编码和测试小增量,记录设计概念和确认测试和测试自动化策略。

  • 编码和测试是同一个过程的组成部分

对敏捷思想不熟悉的人经常会问敏捷测试人员:“在所有故事完成并且可以测试的时候你会怎么做?”经验丰富的敏捷实践者会说:“测试人员必须贯穿整个迭代,整个开发过策划那个。否则就会失败”。

测试人员基于客户提供的例子编写测试,以帮助开发人员理解故事并开始编程。测试和例子提供了一种通用语言使所有人都参与到软件理解中。测试人员和开发人员在编码时紧密合作,他们也会与客户紧密合作。开发人员向测试人员展示他们编写的功能,测试人员向开发人员展示他们发现的异常行为。测试人员随着编码进展编写更多测试,开发人员是其通过测试,测试人员进行更多探索性测试以了解是否生产了正确的价值。每一个敏捷迭代包含了若干持续、快速、增量的测试——代码—— 测试——代码——测试迭代。

当这种合作和反馈周期被打断,并且测试与开发分离时,糟糕的事情会发生。如果故事是在编码之后的迭代中被发现的,开发人员不得不停止新的故事,回忆代码是如何实现上个迭代的故事的,修补它,并且等待其他人测试。在软件开发中没有什么几个事实,但是我们确定缺陷发现的越早,修补的成本越低。

当编码一直由测试指导,编码的同时进行测试,我们更有可能达到客户预期的行为,提供客户所需的价值。测试是团队的职责。如果团队没有这种观念,让所有人想一想对质量的关注、对发布优秀产品的期待和采取哪些措施来确保团队实现目标。

  • 实践之间的协作

单个敏捷开发实践如持续集成能够发挥作用,但是多个敏捷实践的组合比各个部分相加要大。测试驱动设计、共有代码所有权和持续集成一起促进快速反馈、持续改进代码设计和快速产生业务价值。自动化测试很好,但是使用自动化测试驱动开发,随后是探索性测试以发现缺陷或者弱点,分多层次更好。

某些实践单独操作并不好。没有自动化测试,重构是不可能的。通过迷你瀑布型的方式发布小版本会丢失敏捷开发的所有优势。如果你的现场客户没有做决定的授权,那么他对团队的价值有限。

敏捷实践是互补的。花时间理解各个实践的目的,想想如何利用全部优势,针对什么对团队有用做出深思熟虑的决定。

与客户合作

测试人员对敏捷团队的最大贡献之一是帮助客户理清需求并设定优先级,通过预期行为和用户场景的具体例子描绘需求,并把这些例子转换为可执行的测试。测试人员使用业务的领域语言和开发团队的技术语言。我们担任优秀的辅助者和翻译。

千万不要阻碍开发人员和客户之间的直接沟通。鼓励尽可能多地直接交流。使用“三方协作”方法。当需求丢失或者被误解,客户、开发人员和测试人员需要一起解决问题。请客户经常在白板或者其他虚拟工具前讨论问题。如果客户发布于不用的地区、国家,那就使用任何能找到的工具来加强沟通和协作。电视会议、即时消息和 wiki 不能完美的替代面对面的交流,但是也比发邮件或者什么都不做要好。

保持大局观

我们发现测试人员有大局观,通常从客户的角度看问题。开发人员通常关注于实现当前的故事,虽然他们使用测试来指导,但是不得不关注于需求的技术实现。

大局观对团队贡献巨大。测试驱动开发,如果完成得很好,单独的代码没有缺陷。如果新的功能导致一些应用明显不相关的部分崩溃怎么办?一些人不得不考虑这种对较大系统的影响并引起团队注意。如果我们忽略了一些可能惹恼客户的细节怎么办?新的 UI 可能没什么缺陷,但是如果背景颜色使文本难以阅读怎么办?这都是最终用户会注意到的问题。

使用敏捷测试象限作为纲领来帮助规划测试覆盖所有范围。使用测试金字塔思想确保测试自动化的良好投资回报率。通过测试指导开发有助于确保你没有丢失重要的事情,但并不完美。使用探索性测试了解系统应该如何工作,测试应该指向哪个方向。让你的测试环境尽可能与生产环境类似,使用反映现实世界的数据。勤于重新构建一个生产环境类似的场景,如负载测试所需。

团队的每一个人都很容易只关注手边的一个任务或者故事。这是一次只做一块功能的缺点。帮助你的团队后退一步,评估当前的故事如何负责业务的大局。不断问自己如何才能更好的产生真正的价值。

2011-07-09 09:103394
用户头像

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

关注

评论

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

这一周,我肝了公司的聚合代扣支付网关!

诸葛小猿

微信 支付宝 周期扣款 委托代扣 协议扣款

Android |《看完不忘系列》之okhttp

哈利迪

android

谈一谈webpack打包

林浩

Java 大前端 webpack

系统设计系列之如何设计一个短链服务

看山

架构 面试 分布式 架构设计 短链服务

老哥,您看我这篇Java集合,还有机会评优吗?

cxuan

Java 后端

技术管理者带团队的几个实用技巧

Phoenix

团队管理 企业文化 团队 价值观

JVM垃圾回收

羽球

英特尔®AI计算盒参考设计发布 加速智能边缘崛起

最新动态

飞天茅台超卖事故:Redis分布式锁请慎用!

程序员生活志

redis 分布式

编程经典案例之函数

顿晓

函数式编程

用Queue实现Stack,Moya网络框架,Sublime列操作,网络通信协议 非阻塞网络I/O NIO 数据库架构原理 John 易筋 ARTS 打卡 Week 11

John(易筋)

ARTS 打卡计划 数据库架构原理 网络通信协议 Moya 非阻塞网络I/O

智能膜切机,解决手机贴膜行业难题

Geek_116789

第九周总结

晨光

Newbe.Claptrap 框架如何实现多级生命周期控制?

newbe36524

架构 微服务 .net core ASP.NET Core

第九周作业

赵龙

区块链行业发展月度新动态

CECBC

产业落地 政策扶持 差混高新技术 应用场景广泛

创业公司技术体系建设-APM

星际行者

APM

手写一个重入锁

诸葛小猿

synchronized CAS 重入锁 compareAndSwap ReentrantLock

入门WebGL,看这一篇就够了

一颗大橄榄

大前端 WebGL

N皇后问题的回溯法实现(C++)

老王同学

ARTS打卡 第10周

引花眠

ARTS 打卡计划

初识分布式:MIT 6.284系列(一)

Kerwin

分布式 MIT 28天写作

<<前端进阶篇>> PDF 出炉了 — 「阿宝哥」,精心准备的 6 万多字 170 页的前端进阶资料

阿宝哥

大前端

架构师训练营第九周学习总结

qihuajun

第九周作业

晨光

JVM 垃圾回收原理

飞雪

程序的机器级表示-算术与逻辑运算

引花眠

计算机基础

架构师训练营第八章-作业1

A Matt

第九周学习总结

赵龙

架构师训练营第九周作业

qihuajun

图解+代码|常见限流算法以及限流在单机分布式场景下的思考

yes

分布式限流 单体限流 限流算法

敏捷软件测试的七个关键成功要素​_研发效能_崔康_InfoQ精选文章