写点什么

敏捷测试者的担当

  • 2015-12-11
  • 本文字数:2057 字

    阅读完需:约 7 分钟

Agile Testing Days 2015 上,Marnix van den Ent 做了一个报告,在报告中他解释了测试员如何标志并且质疑(测试)过程。他将测试员们看成一个丑角这个观点:“一个团队和团队进度的仆人,就像意大利的丑角一样,测试员在那里帮助大家理解发生了什么”。

InfoQ 采访了 Van den Ent:测试如何被看作提出问题、测试员能做什么来发展询问的艺术、以及一个敏捷测试员如何标志并质疑过程与实践、测试员可以适应并使用的 XP 实践和测试员如何在追溯会议中作贡献。

InfoQ:你提到测试员用测试对产品提出质疑;他们天生富有问问题的能力。你可以给一些测试可以被看作问问题的例子吗?

Van den Ent:在测试象限中,Brian Marick 将支持团队的测试与批判产品的测试区分开来。个人可以看出问封闭和开放问题的不同。

并且,探索性测试是一个极好的例子,在这种测试中我们通过对被测系统提出开放性问题。在有些测试中我们不知道系统的回应——但是我们可以确定真实的回应是不是全部正确。系统行为是什么?一个测试可以让这个问题变得有形,例如一个具体的场景:当一个用户用合法的用户名和不合法的密码登录了三或四次系统,但是在这三到四次登录中间关掉会话很长一段时间,系统会做出什么反应?

InfoQ:测试员可以做些什么来发展提问题的艺术,并帮助敏捷开发团队交付更好的产品?

Van den Ent:这种帮助可能会发生在两个层面上。第一,当看待“我们如何测试产品”时,我们有几个方法来实现。帮助我们弄清楚测试是关于什么的方法是学习(老派的)结构化测试,其中测试活动和测试职责是针对单独的功能、单独的阶段和单独的任务等。这种拆开的方法帮助我们弄清楚在测试中我们要处理什么。并且它以某种方式声明了我们可以或应该怎样做测试。在语境驱动的测试学校,人们比其他测试学科的学校更多地研究怎么测试。这就是“质疑产品的艺术”被培养出来的地方。

接下来,当我们着眼于其他层面来帮助团队交付软件:我们怎么样能帮助或改善他们工作的方式?这也许是 Scrum 管理者与敏捷开发指导擅长的领域。既然这样说,很容易推断出这种假定:责任都降临在了这些角色中而不是其他的人中。当我们做之前提到的测试时,你就会面临那些团队在开发过程中做决定的后果。所以,作为一个测试员就可以看出这些决定的弊端。那时,一个人学会看这些决定并对自己和他帮助改善开发过程的团队提问题。这种问题应该针对一个相对广阔的范围,因此很难阻止它进入一个固定的模式。你甚至不能说封闭性问题不好,因为在某些情况下你也许需要驱使它。

InfoQ:你可以详细阐述一下敏捷测试员如何标志并对团队和团队周围的组织中用到的过程和实践提出问题吗?

Van den Ent:就像我之前说到的,当做测试的时候,个人可以观察局势。例如,如果最重要的用户故事(应该最早被开发的用户故事)的最后一轮测试只可以在第二个冲刺的一半做,你将有预感过程不会像那样乐观。假定用户故事不会像可以问做了什么决定一样大;例如,团队有没有在同时做几个故事上达成统一意见;为什么?

一个不同的情况是一个(外部操作的)产品负责人相信他和团队成员的电话交流足够好,所以他只在一个冲刺中与团队见一次面。在这种情况下,结果表明,产品负责人与管理人员的意见一致阻止了这种情况——然后,也许强烈的个人说服力终究会帮助我们改变这样的情况。

InfoQ:你有一些测试员可以在敏捷开发中适应并使用的 XP 实践例子吗?

Van den Ent:我个人发现了极限编程是一个很好的资源,测试员可以从中学到“新的”对他们团队有用的实践。在极限编程中,一个实践就是共享代码所有权。测试也是这样。有很多这样的团队,其中测试员都有自己的技巧并且他们完全信任自己这样做。这不是很好。团队中的测试员应该意识到共享想法、“设计”测试用例的方法以及帮助提高测试质量和效率的测试。配对和广泛的审查是一个可以令他们做到这点的方法。

XP 还有“简单”这个价值。在很多的情况中,测试员很简单就能前进。但是也有很多情况中,被测试的行为取决于很多参数、值和它们的组合!使这样的测试保持简单才是与团队成员和关键用户交流你的测试的关键。

InfoQ:你可以解释一下,在你看来,是什么使追溯会议在敏捷开发中如此重要?测试员怎么对追溯会议做贡献?

Van den Ent:首先,我要感谢你问出这个问题!学习是敏捷开发的工作方式中一个关键的方面。没有学习就没有敏捷。追溯会议是反映并提升团队工作的标准方式。你经常会听到说追溯会议就像强制性的仪式一样无聊。但是那样的话,你就没有在学习。保持开放性的思维和持续提出问题,以便提升团队的过程,这样能帮助整个团队学习。测试员天生富有问问题的能力。测试员应该学习不仅仅只对产品提出问题,也应该向团队和过程“提出”问题。

查看英文原文: Agile Testers can be a Harlequin


感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群(已满),InfoQ 读者交流群(#2))。

2015-12-11 18:002016
用户头像

发布了 218 篇内容, 共 79.7 次阅读, 收获喜欢 76 次。

关注

评论

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

3dmax的常用功能和使用方法

Finovy Cloud

3D渲染 3DMAX

4道数学题,求解极狐GitLab CI 流水线|第2&3题:父子流水线 + 多项目流水线

极狐GitLab

ci DevOps pipeline 极狐GitLab 流水线

袋鼠云产品功能更新报告04期丨2023年首次,产品升级“狂飙”

袋鼠云数栈

软件测试 | App控件定位

测吧(北京)科技有限公司

测试

基于 Flink 的小米数据集成实践

Apache Flink

大数据 flink 实时计算

@所有人,OceanBase DevCon • 2023来啦!

OceanBase 数据库

数据库 oceanbase

谈JVM参数GC线程数ParallelGCThreads合理性设置

京东科技开发者

线程 JVM cpu GC线程 ParallelGCThreads

ChatGPT 最好的替代品

图灵社区

机器学习 Transformer BERT ChatGPT

软件测试 | 录制Appium测试用例

测吧(北京)科技有限公司

测试

信通院发布“2023可信AI案例 知识计算应用优秀案例”, 百度知识中台三大案例入选

极客天地

机器学习洞察 | 一文带你“讲透” JAX

亚马逊云科技 (Amazon Web Services)

软件测试 | adb命令的组成

测吧(北京)科技有限公司

测试

软件测试 | 高级定位技巧

测吧(北京)科技有限公司

测试

可靠、安全、稳定,开源高质量项目 | 亚马逊的开源文化

亚马逊云科技 (Amazon Web Services)

中国人寿业务稳定性保障:“1+1+N” 落地生产全链路压测

TakinTalks稳定性社区

软件测试 | Appium架构介绍与环境配置

测吧(北京)科技有限公司

测试

Wallys|QCN9074/QCN6024/ 5G 802.11ax|Does QCN9074-5G module support W56?

Cindy-wallys

QCN9074 QCN6024

【2.10-2.17】写作社区优秀技术博文一览

InfoQ写作社区官方

热门活动 优质创作周报

Slurm集群调度策略详解(2)-回填调度

慕冰

Slurm 回填调度

设计模式第七讲-外观模式、适配器模式、模板方法模式详解

C++后台开发

设计模式 后端开发 Linux服务器开发 适配器模式 C++开发

ChatGPT 最好的替代品

图灵教育

机器学习 BERT ChatGPT

实现“无感知”的网络运维,新华社融媒体流量分析平台的创新之路

智维数据

大数据 防火墙 数据可视化 智能运维 运维安全

OceanBase 4.0解读:兼顾高效与透明,我们对DDL的设计与思考

OceanBase 数据库

数据库 oceanbase

ChatGPT搜索风暴

OneFlow

人工智能 深度学习

理论+实践,揭秘昇腾CANN算子开发

华为云开发者联盟

人工智能 AI 华为云 企业号 2 月 PK 榜 华为云开发者联盟

软件测试 | App常见Bug解析

测吧(北京)科技有限公司

测试

怎么编写接口测试用例?

Liam

测试用例 如何编写测试 测试用例设计

模块6 拆分电商系统为微服务

KING

软件测试 | 元素定位方式与隐式等待

测吧(北京)科技有限公司

测试

拜占庭将军问题和 Raft 共识算法讲解

京东科技开发者

算法 分布式系统 拜占庭将军问题 raft共识算法 日志同步

软件测试 | App控件交互

测吧(北京)科技有限公司

测试

敏捷测试者的担当_研发效能_Ben Linders_InfoQ精选文章