写点什么

敏捷方法在测试计划中的应用

  • 2016-04-21
  • 本文字数:4596 字

    阅读完需:约 15 分钟

Agile Testing Days 2015 大会上,Eddy Bruin 和 Ray Oei 解释了如何在不编写大型测试计划的情况下,满足干系人对测试用例、测试计划和其它测试工件的需求。

InfoQ 就测试计划在敏捷中的应用、如何让干系人意识到他们能够影响质量,以及他们推荐的敏捷测试实践问题对 Bruin 和 Oei 进行了采访。

InfoQ:在瀑布或者敏捷项目中您觉得测试计划有什么问题?这些问题相似或者不同吗?

Eddy Bruin:我记得我对我编写的第一个主测试计划非常满意。我觉得一切都一目了然。编写这份测试计划花费了我一个月的时间,但我发现没有人详细阅读这份计划,我仍然需要为计划中的许多内容点争论。如果当时我花费一个月的时间跟大家交流,边测试边解释,那么我会更加的成功。就是那个时候我意识到编写如此一个计划非常的浪费时间。

从那时以来,我收到过数份测试计划并阅读了它们。我的结论是大多数计划包含的信息都是不相关和过时的,对产品质量或者测试流程没有帮助。它们太不灵活且费时费力。

我发现敏捷中的测试计划有个不同,他们会再一次解释 Scrum 的规则,然后尝试以瀑布的方式在测试中进行压缩。在我看来,它们都是一流的计划,但是用在了错误的敏捷过程中。

Ray Oei:在我的定义里,测试计划就是一份冗长的文档,遵循一些标准或模板。这些测试计划的通病是花费太长的时间编写,并且在大部分情况下,几乎没人阅读。它更多的是一个过程工件而不是测试工件。许多我遇到的测试人员在尝试遵循计划时总是会遇到问题,并受到“为了测试我需要做什么?”的困扰。并且某些时候你可能发现所有计划的内容或多或少相同,并不能真正帮助需要测试的内容。因此,你试图忽略它们。

当所谓的敏捷项目需要测试计划时,并且它已经在我身上发生过,这种情况有个明确的迹象是它不是敏捷环境。在这些案例中我曾遇到的一个问题是有些人将工作方式强加给测试人员,首先因为测试阶段的描述,所以他们将测试人员与团队隔离;其次与团队的努力建设没有一点联系。这不利于团队精神。

InfoQ:在 Agile Testing Days 大会上,您把您的演讲叫做“Placebo Test Management”。您能解释一下它的含义吗?

Ray Oei:它描述的是由于我们交付的内容与预期提供的解决方案相比,或多或少具有欺骗性(fake)所造成的影响。像在医学方面,通常很有效果。它能造成控制错觉(illusion of control),这种错觉满足了很多人。当然, 它也会引发一些反应。我们不想欺骗或者仅仅让管理者满意。通常,在我们能够以他们想要的方式交付价值之前,我们需要先建立一个共同的基础,使得看上去似乎在做预期的事情。展示有价值的结果才是关键,这样有助于说服人们相信事情能够以与他们预期不同的方式完成。然而,这在流程 - 饥饿(process-hungry)环境中是一个很大的挑战。

Eddy Bruin:一年前当 Ray 和我讨论测试计划的时候,我们得出结论,我们倾向于拥有解释为什么、如何测试和测试什么的替代方案。然而,在某些情况下我们被告知需要基于公司模板交付一份测试计划或者测试报告,“因为流程强迫我们这么做”。

因为我们认为这是一个错误的观点,所以我和其他测试人员开始敷衍测试计划。我们寄出无意义的测试计划,仅仅交付无意义的模板,或者提交复活节彩蛋,目的是为了表明测试计划不能用来提高测试或者测试未被合理解释。然而这些行为确实能够取悦负责监护流程的管理者:项目经理或者质量流程管理者(很高兴)看到流程被遵守。

流程规定必须编写测试计划。如果管理者看到带有“测试计划”附件的邮件,他们会选中复选框。即使文档中没有内容,流程遵循者也高兴。很不幸在某些情况下会发生这种情况。我们意识到这些具有欺骗性的测试计划触发了安慰剂效应。我们就是这么杜撰“安慰剂测试管理(placebo test management)”短语的。

InfoQ:您觉得在敏捷中还需要测试计划吗?它们能起到什么作用?

Eddy Bruin:计划对测试而言其本身是一个有用的工件。它能够塑造上下文,能够对我们自己和其他人解释我们将如何实施测试。我的问题是编写的计划所包含的信息已经可以获取并且不断变化,因此编写这么一份计划是低效率的。像在哪种测试环境下测试和覆盖哪种风险这种实用性值得拥有和沟通。同样协议中的测试范围(比如我们对哪种浏览器进行测试)很容易写下来。

然而,Scrum 框架已经为此提供了一个有用的工件:完成的定义(DoD)。这份文档会发生变化,更重要的是它是沟通的象征(token of conversation)。“沟通的象征”的意思是 DoD 仅仅是伴随故事的一种结果,一种陈述。只有在沟通中我们才能描述故事,而不仅仅是给每个人发送一份 DoD 副本。也就是说,我确实喜欢拥有合适的测试远景文档。它可以是一份 PPT 或者思维图。测试文档跟 DoD 一样会发生变化。例如保持团队敏捷从而允许在回顾中改变文档。

Ray Oei:这取决于你对测试计划的定义。在传统形式下,我会说不需要。

在我看来,完成的定义包含了一部分计划。在一定程度上用户故事本身由业务所描述:为用户故事定义的验收标准,可能存在的整体约束,产品需要的工作环境,终端用户等等。我们可以找到许多方式在团队内,与 PO 和干系人进行沟通。例如,我自己就喜欢思维图,但是 BDD 也非常的有用。最后,这取决于具体环境。没有明确的针对所有事情的解决方案。在这方面,与我们不同的“医学(medicines)”概念始终是正确的:你必须寻找能够在具体环境下起作用的东西。反复试验,检查并调整。这不就是敏捷吗?

InfoQ:您能详细说明如何和敏捷一起使用测试管理方法(TMap)类型的测试计划?

Ray Oei:正如我在我的演讲中解释的,它更多的是一种木马病毒而不是安慰剂。在我的案例中,外部项目组织坚持需要文档。但是文档内容经过定制以支持开发团队正在探索的敏捷倡议。因此,我描述了启发式测试策略模型(来自 James Bach),用来解释我们将生成测试用例的方法和基于会话的测试管理(来自 Joh Bach)——管理者尤其“钟爱”“管理(management)”一词,此外还用此来描述我们将组织测试的方法。当然,整个过程就是著名的 Scrum 循环图。它被大众接受。并且当我被问到什么时候测试用例可以准备妥当的时候,我可以指着商定的方案并解释说所有的事情都在按部就班的前进。

InfoQ:您有哪些案例可以说明您是如何让干系人意识到他们能够影响质量的?

Eddy Bruin:在这方面关键在于参与。几年前,一个业务经理告诉我“我们需要更多的测试用例!请您把它们写进测试计划。”我回复到,请问您需要更多测试用例的原因是什么。“否则我们如何了解系统的质量?另外我需要维护软件。我想知道它的反应。”

很明显,业务经理和他的团队需要两件事:1)对产品质量的自信和 2)了解产品是如何运作的。从那时起,我邀请他的团队参加 Sprint 评审,评审后用一个小时的时间和他们一起测试。事实证明他们都是非常优秀的测试人员,自从我引导他们学习系统后,我再也没有收到编写测试用例的请求。除此之外,在 Sprint 评审期间他们提供了更多的反馈,这些反馈着实提高了质量。在我目前的工作中,我们非常重视 Sprint 评审,我们认真准备评审,这样人们可以自己操作产品,在迭代中针对固定领域提供反馈。

Sprint 评审的几点思路:

  • 创建活动挂图,参与者可以在上面留下自己的反馈。也可以是积极的反馈!(在演讲中你可以看到一个类似的活动挂图的案例。)
  • 准备测试数据,并打印出来。
  • 有多个可用的设备和工作站,这样人们可以检查你的产品
  • 邀请人们自己操作应用(不要仅仅展示)

Ray Oei:与干系人交流,要有耐心不要害怕重复。不是每个干系人都希望或者觉得有参与的必要,他们仅仅想要一个可工作的产品。通常有帮助的是演示,更多的是演示之后的讨论。让干系人体验到他们的投入得到了使用和欣赏非常的重要。给他们机会分享他们的假设、期望和需求。如果可能给他们全天候的产品访问权限。让他们测试。当然这也是有风险的。如果产品过分不稳定,你可能不会获得干系人的信任;结果可能与预期相反。不幸的是,在干系人参与都成问题的情况下,通常最终结果也会让他们失望。

InfoQ:您有案例说明如何在敏捷中计划测试吗?

Eddy Bruin:如果你的工作环境是 Scrum,所有测试最好在开发软件的迭代过程中完成。我发现现实往往相反。向敏捷过渡的企业其很多的测试阶段并没有简单的消失。端到端测试和性能测试通常在 Sprint 之后实施。我所追求的是不断地让测试负责人参与进来,并向他们展示如何可以更早地执行这些测试。归根结底都是为了尽可能快地缩短反馈环。如果我们的软件在市场上有助于实现业务目标,那么软件就应该视为一个解决方案,因此我们越早有可工作的软件,就越早可以测试。

业务经理要求在测试计划中体现更多测试用例(后期反馈)的故事与业务经理参与每两周一次的 Sprint 评审两者之间的对比就是缩短反馈环的案例。另一个案例是不要等到演示的时候才去展示产品。一个可替代的方案是每做完一些测试,就向团队或者产品负责人询问结果。

Ray Oei:我试图围绕一个故事、期望的产品或者任何看上去重要的东西发现尽可能多的问题。创建一个我们正在构建产品的模型,和思维图有助于我组织测试。提出问题。如果可能的话调查研究。我发现当我听到程序员讨论事情的时候,我经常想起一些需要测试的内容。我会遍历代码。当有人告诉我,我不需要因为一些不明原因检查代码时,那么我肯定会看一眼代码。那是一个“计划”吗?如果你认为计划是开始测试前对某个时期的设想,那么它就不是的。但是我又有测试的想法,并且我在努力尝试执行这些想法。而且说实话,事情的发展并不总是跟我预料的一样。有时在我有时间组织它们之前,我的一些想法已经过时了。我认为我的主要指导计划就一个问题:“现在或者未来,这重要吗?”。

InfoQ:有没有一些您想推荐的具体的敏捷测试实践?

Eddy Bruin:有一大堆的敏捷测试实践:结对编程、实例化需求(ATDD/BDD)、TDD、大量的启发式测试等等。对我而言总是非常优秀的一个实践是在所有测试活动中进行沟通。当规划测试、汇报测试和解决 bug,甚至是当展示我们实际意图构建的产品和应该给公司带来什么产品时,我总是努力尽可能地透明化。为此我最常用的策略是拥有尽可能多的信息辐射体。墙上的活动挂图、白板和便利贴越多,开始沟通就越容易。

Ray Oei:不是具体的敏捷测试实践。我认为关键是沟通:交谈与倾听。或者更好的是:提出问题,并花时间倾听和理解。了解相关的领域和业务,和使用的技术。了解你共事的成员。同样发现你自己在那的角色和行为。我们倾向着眼于别人,认为他们应该 / 可以 / 必须完成的更好——但是你自己呢?

展示你正在做什么,已经做了什么。甚至如果需要,展示你犯错的地方。这有助于建立信任。这方面并不是航天器学,没那么复杂。虽然,作为技术人员,我认为航天器学比人文科学更加容易。

关于受访者

从 2008 年开始 Eddy Bruin 一直充当测试顾问的角色。他热衷于敏捷、测试、易用性和移动领域。他帮助组织实现反馈环从而交付更好的产品。作为敏捷测试教练,Eddy 喜欢提供敏捷测试培训,喝着特制啤酒讨论话题。目前 Eddy 是一家国际速递的测试技术总监。

Ray Oei 是一名经验丰富的敏捷教练和有扎实编程技术的测试员。他能够从不断学习新事物中获得能量,包括但不限于软件测试行业。Ray 是 DEWT(Dutch Exploratory Workshop on Testing) 的创办成员,软件测试协会(AST)成员,AST BBST 课程的首席教官,TestNet 工作组培训 & 教练成员。他是 AVG 创新实验室的 QA 团队主管。

查看英文原文: Agile Approaches in Test Planning

2016-04-21 19:332812
用户头像

发布了 92 篇内容, 共 24.8 次阅读, 收获喜欢 4 次。

关注

评论

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

这个让全网眼红的红利行业,还需要人才吗

千锋IT教育

程序员被京东淘汰转身痛哭,HR扎心了

千锋IT教育

基于 Flink x TiDB,智慧芽打造实时分析新方案

Apache Flink

大数据 flink 编程 流计算 实时计算

大厂面试真的很难吗?字节跳动3面+腾讯6面一次过,谈谈我的大厂面经

程序知音

Java java面试 程序员面试 后端技术 八股文

Golang 使用过程中遇到的小技巧(一)

皮特王

如何让工业制造拥有更强的“数字内核”?

天翼云开发者社区

大咖说 | 云采销助力中小企业获客提升300%,交易提效58%

大咖说

数字化升级 云采销

语音交友APP:搭建部署流程及主要功能介绍

开源直播系统源码

软件开发 直播系统源码 语音直播系统

DR600VX-Atheros-QCA9880-2T2R-MIMO-802.11ac-Mini-PCIe-Wi-Fi-Module-Dual-Band-2.4GHz-5GHz

wallys-wifi6

RT-Thread记录(十二、I/O 设备模型之UART设备 — 使用测试)

矜辰所致

RT-Thread 8月月更

云成本支出不受控制怎么办?教您一招!

行云管家

云计算 云资源 云成本

“客户体验管理”这么热,究竟能给企业带来什么变化?

科技怪咖

搜索引擎分布式系统思考实践

得物技术

搜索引擎 分布式系统

基于 Flink 构建大规模实时风控系统在阿里巴巴的落地

Apache Flink

大数据 flink 编程 流计算 实时计算

ONES 团队版50人以下免费,助力中小企业「弯道超车」

万事ONES

2022“易观之星”年度奖项启动征集,发现卓越数智力量

易观分析

报名 数智化 易观之星

天翼云入选可信边缘计算推进计划与分布式云扬帆计划首批成员单位!

天翼云开发者社区

Zebec社区利好频传,Galaxy Project上领取专属Zebec OAT

小哈区块

工程师如何拥抱数字化转型?

星策开源社区

工程师 产业数字化 数字化时代 智能化转型

今日头条三天点击破亿!四天精通springcloud微服务架构

退休的汤姆

社招 java架构师 秋招 #java spring、

金山云团队分享 | 5000字读懂Presto如何与Alluxio搭配

Alluxio

金山云 presto Alluxio 大数据 开源 8月月更

什么是外网?外网需要做等保吗?与内网的区别是什么?

行云管家

等保 等级保护 内网 外网

图灵访谈 | Vue.js官方团队成员霍春阳:跨专业做程序员,是什么感受?

图灵教育

RT-Thread记录(十三、I/O 设备模型之PIN设备)

矜辰所致

RT-Thread 8月月更 I/O设备模型

DR882-Qualcomm-Atheros-QCA9882-2T2R-MIMO-802.11ac-Mini-PCIe-Wi-Fi-Module-5G-high-powe

wallys-wifi6

MobTech ShareSDK Android端快速集成

MobTech袤博科技

android Android Studio SDK 教程

百度App 低端机优化-启动性能优化(概述篇)

百度Geek说

性能优化 运维 服务器

人工智能应用落地的两难

felix

人工智能 开放api 算法模型

Zebec社区利好频传,Galaxy Project上领取专属Zebec OAT

西柚子

天翼云为这场酷炫的元宇宙会议做了这件事

天翼云开发者社区

天翼云TeleDB系列产品升级发布会开幕在即,精彩邀您共鉴

天翼云开发者社区

敏捷方法在测试计划中的应用_Scrum_Ben Linders_InfoQ精选文章