敏捷测试指引(7)- 敏捷项目中的测试员

翻译 2007年09月27日 16:49:00
 
敏捷测试指引(7)- 敏捷项目中的测试员
陈能技
2007-9-27
 
原文:Agile Testing Directions –Testers on agile projectsBrian Marick)
 
敏捷项目中是否应该有测试员呢?
 
首先:替换测试员的是谁?是让非测试专业人员(程序员、业务专家、技术文档编写人员等)来执行这样的活动:帮助创建指导性的例子和对产品进行批判?还是,反过来,让测试员来做编程、业务分析、技术写作等工作呢?把“测试”仅仅作为技能的集合而存在,在项目中拥有充足的数量,用于服务所有需要这些技能的任务。
 
为什么非专业测试员会是个坏主意?这里是一些可能的原因:
l         测试技能很难学到。如果你尝试作为测试员同时是程序员,或者作为测试员同时是技术文档编写人员,你不会拥有所需要的最少的技能来成为足够好的测试员。
 
l         假设你是世界上最好的篮球运动员,同时是最棒的洗车工。你可能还是愿意让别人帮你洗你的车,因为比起你自己洗车省下的钱,你可以赚取更多的时间来打篮球。这就是相对优势的一个例子。因此,为什么不让一个懂得测试的诀窍的人只是做测试,而让一个在编程方面相对强的人专注于编程呢?
 
l         测试虽然说不上是是一种天生的技能,但是某些人就是喜欢吹毛求疵,有些人则不擅于批判。
 
l         很多人在找自己工作的错误时会有困难。因此把测试和其它任务混在一起的话会测试得很糟糕。中间存在太多情绪上的利益冲突了。
 
l         测试员能从“有用的无知”得到很多益处。不知道实现的细节使得他们更容易从用户的角度看什么类型的错误是用户容易犯的。
 
论据
让我首先解释一下“最小所需技能”和“相对优势”。这些论据在面向技术的产品批判中是最强的,像安全性测试或可用性测试。在一个实际的项目,我一定能看到专门的安全性测试员。在小一点的项目,我能看到临时出现的安全性测试员。
 
对于我在面向业务的产品批判中所依赖的探索性测试员,我不那么确信。探索性测试员发现的这么多的bug中,很多是程序员可以预防的,如果他们能经常看看那些bug并使它们内在化。把bug内在化的最好的途径是把程序员纳入到寻找bug的行列,而不仅仅是修改bug。如果测试人员来写其中的一些代码,则bug会少些。因此这个论据是反对拥有专业的测试员的。
 
换言之,我认为人们都有最小所需的探索性测试技能。
 
我想相同的原因适用于矩阵的左边-面向技术的检查性例子(单元测试)和面向业务的检查性例子(客户测试)。我把这些方面的东西教给测试员。程序员也可以做。业务专家也可以做,虽然可能很少有人有机会达到最小技能的水平。那是为什么面向业务的例子是被团队创建的,而不是仍过墙的。实际上,团队沟通是如此的重要,以致应该把所有相对优势的影响淹没。
 
现在,让我们看看所谓的“天生的能力”。当Jeff Patton给我们展示以使用为中心的设计的例子时,其中一个练习是为一个假想的会议文件评审系统创建角色。我当时创建了类似“不情愿的文件评审者”、“过度疲劳的会议主席”、“拖延的作者”等角色。有些人评价说,“你能看得出Brian是个测试员”。我们都轻笑为什么我会倾向于悲观的例子。
 
但是最重要的是 – 那是学术行为。我这样做是因为我有意识地去找出那些会跟开发人员希望不一致的操作系统的人。我的预感是我天生比别人更倾向于批判,但是我学着成为一名合适的测试员。我想普通的程序员也可以。我还没有碰到过一名程序员是过分乐观主义者,以致认为其他人的软件是世界上最好的。
 
是你自己引起的所谓“情绪上的利益冲突”。我曾经让Elisabeth Hendrickson对我的一个程序进行探索性测试。我颇为得意-我认为我的面向技术和面向业务的例子都通过了。当然,她很快地发现了一个严重的bug。我不仅仅是震惊,而且做出了很多测试员都很熟悉的自我保护性的反应。
 
后来我在最后期限之前做了一些探索性测试,意识到我在用户界面的“不重要的”部分编码工作做得不够好,但是我感觉不情愿去攻击这些GUI,因为我实在是不希望修改bug。
 
因此这是个真正的问题。我希望我们可以通过一些实践来减少它。例如,就像结对编程的程序员倾向于保持诚实地重构,那么在探索性测试时保持诚实地攻击代码。在进度压力下不愿意重构 – 导致的是设计的“债”的积累 – 不是一个可以永远摆脱的问题,但是项目组要学会处理它。也许对于情绪上的利益冲突也一样。
 
跟情绪上的利益冲突相关的问题是“有用的无知”。假设是在第五次迭代。由测试员/程序员/其他人员组合在一起,从开始就工作在一起。当对产品进行探索时,他会有开发习惯。如果有两种方法做某件事,他会选择同一个。当他使用产品时,他不会犯很多概念上的错误,因为他知道产品应该是怎样工作的。他的团队已经写了很多指引性的例子 – 在他们做这个的时候,已经建立了一个清晰的“理想用户”应该是怎样的一个模型,他们会在想象其他类型的用户会怎样方面碰到麻烦。
 
这是个很难解决的问题。角色扮演能帮助解决。Elisabeth Hendrickson教测试员在测试过程中要时不时假定极端的人物。如果Bug Bunny来使用这个产品会发生什么事情呢?他是个麻烦制造者,总是探究别人的弱点,总是愚弄权威。想象一下卓别林在摩登时代的角色:天真、毫无准备、被迫工作得更快。另外一个有用的技术是Hans Buwalda的肥皂剧测试方法(Soap Opera Testing)。
 
我希望这些技术能帮助解决问题,尤其是结对在一起时(互相之间会感染)。但是我不禁要想伪造的无知不能替代真实的东西。
 
组队
因此,是否应该包含测试员在敏捷项目中呢?要看情况而定。但是如果我负责一个重要的产品的敏捷项目组的组队,我会考虑以下方式作为默认的做法:
l         我会找一到两个拥有丰富测试经验的人。他们应该懂一些编程的知识。他们应该擅长于跟业务专家讨论并很快地获取一些领域知识。首先,我会依靠他们来确保面向业务的例子可以很好地工作。然后我会期待他们学习更多的编程,编写基础代码,教程序员,成为程序员一样的人。
 
个性非常重要。他们必须喜欢新奇的事物,他们不应该把他们的个性情绪化地包含到工作中,他们应该习惯于服务其他人。
 
l         如果这些人在探索性测试中做得很出色应该受到赞赏。但是,不管怎样,整个项目组都会得到关于探索性测试的培训。我会让外部的探索性测试教练定期地来造访。他们既会扩展培训,还会做一些探索性测试。作为一个持续的监督,用于防止项目组过于习惯于产品而不能找到足够的bug。
 
l         对于非功能缺陷,像可用性、安全性、性能比较看重的产品,我会购买专门的技术(定点的顾问、造访型的顾问、或者招聘这方面的专门技术人员)。他们会对创建产品提出建议、培训项目组、测试产品。
 
l         我会极力让真正的用户参与(不仅仅是代表用户的业务专家)。可能会让项目组成员到用户那边,而不是反过来。我会让项目组成员把自己想象成人类学家来研究产品所在的领域,不仅仅是倾听bug和功能特性的请求。
 
是否有测试员在项目组中?谁关心这个?- 总之会有好的测试,即使指出某个活动中有测试会日益地困难,像说“那里,就在那里。那就是测试,没别的”一样。
 
 
 

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

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

究竟什么是敏捷测试

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

什么是敏捷软件测试

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

敏捷开发中的测试

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

敏捷开发之道(七)测试

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

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

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

项目级敏捷流程中的角色说明与关键职责

项目级敏捷定义:项目级敏捷指产品TR2完成系统设计后,在TR2-TR4A范围内,具有迭代、持续集成和自适应特征的软件开发模式。项目级敏捷聚焦单个项目组或多个项目组协同的软件开发过程和能力改进,对IPD...
  • zj0910
  • zj0910
  • 2014年03月27日 22:28
  • 2278

敏捷开发流程

反应快速灵敏。   在敏捷软件开发领域,更注重的以人为核心,迭代,循序渐进的开发方法。相比传统的开发方法,这种方法能更快速的开发,上线,反馈,调整、迭代。以敏捷的姿态去发展产品。 ...
  • mexia
  • mexia
  • 2017年01月04日 16:30
  • 2171

敏捷开发在项目中的应用心得

关于敏捷开发部分思想在项目中的应用心得
  • lqh4188
  • lqh4188
  • 2015年04月23日 17:21
  • 1119

敏捷测试与传统测试的区别与最佳实践

敏捷测试并不是一种新的测试类型,也不是一个新的测试阶段,更不是一种全新的测试方法论。通俗地讲,在敏捷开发过程中进行的测试就叫敏捷测试。   它是一套测试解决方案、一组实践或者由一定顺序的测试活动...
  • wangxin1982314
  • wangxin1982314
  • 2017年03月08日 11:20
  • 417
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:敏捷测试指引(7)- 敏捷项目中的测试员
举报原因:
原因补充:

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