敏捷测试指引(5)- 用面向业务的例子批判产品

翻译 2007年09月26日 23:35:00
 
敏捷测试指引(5)- 用面向业务的例子批判产品
陈能技
2007-9-24
 
原文:Agile Testing Directions – business-facing product critiques(Brian Marick)
 
为了帮助讨论和理解,我把“敏捷项目中的测试”这一主题分解成4个区分的主题。今天,我开始讲矩阵的右边:产品批判。
 
使用面向业务的例子来设计产品是好的,但是假设例子是错误的怎么办?谁都会犯错误。业务专家会忘记一些用户真正需要的东西。或者业务专家错误地表达了需求,而程序员却非常忠诚地实现了错误的东西。
 
那些错误,如果记起来了或注意到了,则可能会当作bug,也可能被认为是需要的功能特性。但两者的界限很模糊。我会简单地把它们叫做“问题”。
 
问题是如何引起项目组的注意的呢?
l         很多敏捷项目组会在一个迭代结束时向业务专家和感兴趣的外部人员演示软件系统。这时候会是激怒某个人的时候,“噢…我是那样说过,但是我不是这个意思”。
l         敏捷项目喜欢频繁地发布软件给它的用户(可能比用户希望更新的频率还要频繁)。当用户试用产品的时候,他们会指出存在的问题。
 
这些反馈循环很紧凑,比传统的项目要紧密,因为敏捷项目喜欢短的迭代。但是它们不是最理想的。业务专家可能由于过于靠近项目而不能以新的、没有偏见的眼光去发现问题。用户通常不报告他们在软件使用中发现的问题。当他们反馈问题时,报告得又不够专业以致没办法执行。而反馈的周期不能像敏捷项目希望的那样的频繁。可能仅仅是针对一行代码的改变的反馈,但是需要等上3个月才能从用户那收集到。
 
因此,我们需要额外的产品批判形式 – 能注意到用户会怎样,而且能及时注意到。
 
产品批判的方式拥有前期创建的例子所不具备的资源:一个新的迭代版本的真正工作的软件。当你描述某些目前不存在的东西的时候,你是在脑海里操作一个抽象的东西,一个你想象中的物品。当你亲手操作一个产品的时候会激发不同的理解和判断。你可能注意到,当试驾一辆汽车的时候,你不会专注于它的规格说明。操纵是与思考不一样的。
 
因此,面向业务的产品批判应该专注于操作方面,尝试逼近真正的不同用户的体验。就像James Bach,Cem Kaner,Elisabeth Hendrickson他们所说的探索性测试(Exploratory)的形式。
 
进一步的,我发现我们在尝试至少5种类型的探索性测试:
1、 一个探索性测试员
2、 结对探索性测试员。James Bach 和Cem Kaner可能在这方面有最多的经验。
3、 探索性测试员与一个程序员结对。Jonathan Kohl会在2004年1月的STQE杂志(http://www.stqemagazine.com/)有一篇这样的文章。我在这方面没有什么经验,程序员也喜欢这样的方式。值得注意的是,当我在RoleModel Software进行这种方式的时候,它导致了一个有趣的并且有用的关于基础程序的讨论。那样的话,它成了一种类似回顾的方式,这进一步让我相信它是迭代结束时很好的一种活动。
4、 让探索性测试员与项目中的业务专家结对
5、 让探索性测试员与感兴趣的非参与者(用SCRUM的术语来说就是“chickens,小鸡”),例如经理主管、新用户等等。
 
对于每一种,我们应该探索关于什么时候测试员应该是项目组外的人的问题。这些外部的测试人员不会存在偏见和先入为主,但是存在缺点就是:他们需要花更多的时间来学习一些基本的东西。那也会使发现的问题存在一些偏离。
 
当我一年前开始在敏捷项目谈论探索性测试的时候,我想它会在发现bug的同时对提出一些大胆的关于产品的新构思有启迪作用。一个过程能发现两类问题。有一段时间,我把它叫做“探索性学习”来强调它的扩展的角色。
 
后来我推断这两个目标不能很好地走在一起。因为找bug实在是太诱人了 – 对于功能特性的思考会在探索性测试的过程中迷失。有些时候能同时出现,但是不足够。所以我想可能需要一个单独的功能特性的脑力风暴活动。关于这一点,现在我还没有什么特别好的主意。“需要进一步的研究”。
 
 
 
 
 
 
 
 
 

微服务架构设计 第一步: 从特性到业务场景

为何需要微服务? 目的只有一个: 比竟争对手能更快的响应市场的变化与客户的诉求。 所以, 微服务的分析与设计, 必需要掌握两个核心的原则: 1. 从外部的业务场景, 驱动微服务的分析与设计。 ...
  • u011790275
  • u011790275
  • 2016年09月08日 22:16
  • 1133

我们的敏捷之路——技术转型篇

在上一篇敏捷之路中主要讲述了我们软件开发方法方面的改进历程,有近一年的时间里完成了试点团队由do whatever向敏捷开发的迁移。在这一篇文章中讲介绍我们在这个迁移过程的技术转型的故事。...
  • zhaoenweiex
  • zhaoenweiex
  • 2017年04月01日 22:19
  • 517

敏捷开发中测试角色的窘境

敏捷开发中测试角色的窘境 先说说敏捷开发中码农哥哥与测试妹妹的一段恩怨情仇: 测试妹妹:需求文档在哪里? 码农哥哥:这个...,没有需求文档,产品经理发了我一句话,后来直接和我说了要求,很简单,我...
  • yzsind
  • yzsind
  • 2016年01月24日 22:44
  • 4021

究竟什么是敏捷测试

时至今日,还讨论这样一个老话题,是否感觉老调重弹?因为两年前(2010年底)时任谷歌中国测试经理的段念先生就写了一篇文章《什么是敏捷软件测试》(刊登在InfoQ网站上[1]), 就已经谈到这个话题,“...
  • KerryZhu
  • KerryZhu
  • 2013年04月17日 10:26
  • 11288

什么是敏捷软件测试

 敏捷的理念已经深入人心,开发过程已经渐入佳境,测试的处境却稍显尴尬。测试从业者应该何去何从,怎样才能拥抱敏捷,体现出自己新的价值呢?InfoQ特地邀请了来自Google的敏捷测试专家段念,为读...
  • wauit
  • wauit
  • 2015年06月26日 11:50
  • 637

敏捷开发中的测试

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。 敏捷开发过程中,很多时候测试人员就时常被当成项目无法加快的阻力,一下这边爆一个bug,那边有个缺陷,所...
  • Trinity_Techologies
  • Trinity_Techologies
  • 2017年03月20日 16:22
  • 264

产品项目里的九个敏捷开发实战经验

[摘要]   敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支...
  • buding_pmp
  • buding_pmp
  • 2016年11月03日 17:37
  • 1374

敏捷开发之道(七)测试

在上一篇的博客敏捷开发之道(六)计划(续)中我们介绍了一下敏捷开发的计划和简单的执行,接下来我们针对在开发中不可避免的测试进行一下介绍。...
  • zs15932616453
  • zs15932616453
  • 2014年02月28日 13:55
  • 2109

自动化测试在敏捷开发的的一些心得

在“敏捷”开发过程中,自动化工程师先对哪一部分功能进行优先的用例实现:可以从以下几个方面进行考虑:1.优先考虑数据对比类型的功能,这种功能人工操作比较费眼力和时间 2.优先考虑已经测试出问题的功能,这...
  • zhang103886108
  • zhang103886108
  • 2014年10月15日 16:35
  • 835

OpenStack架构企业IT应用的敏捷实践

OpenStack架构企业IT应用的敏捷实践 发表于14小时前| 203次阅读| 来源《程序员》电子刊| 0 条评论| 作者张小斌 肖何 谢胜 OpenStack云平台敏捷架构应用 ...
  • starzhou
  • starzhou
  • 2015年11月13日 08:38
  • 492
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:敏捷测试指引(5)- 用面向业务的例子批判产品
举报原因:
原因补充:

(最多只允许输入30个字)