2019-11-20 09:34:20 qq_44614026 阅读数 44

本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 2)。每天早上十点,在固定的时间和会议室里面,团队会举行站立会议。这时候,团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务,所遇到的困难和当天要完成的任务。同时,项目经理更新 Sprint Backlog(一张制作精良的 Excel 表格),并及时解决每个人所提出的问题。

在这里插入图片描述

测试人员需要具备的素质

测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号:测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求:

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力 -> 软件质量工程师

总结而言,有三方面的基本素质要求:代码编写(Coding)、测试 (Testing) 和分析 (Analysis)。

在很多其他的开发流程中,各个测试阶段对测试人员的能力有所不同;有时候侧重分析(比如系统配置测试),有时候侧重代码编写 ( 比如功能测试 )。但是,在敏捷开发流程中,测试人员需要结合这三方面来开展工作,只有这样才能真正反映敏捷测试的本质:简单而高效得应对变化。

测试人员的主要职责

在敏捷软件开发中,测试人员的职责有三个主要方面:

定义质量 (Define Quality)

这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流,从自己的经验出发,共同为产品功能制定质量要求。

交流缺陷(Communication)

敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能,测试人员应该抓住细节,寻找设计中的“missing door”;另外,开发人员使用单元测试来保证产品的基本质量,测试人员可以使用验收测试(Acceptance Test)来鉴定客户需求与实际成果之间的不一致性。

及时反馈 (Feedback):

敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。
这样一来,团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话,敏捷流程要求每天汇总质量问题。在我们的项目中,内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。
另外,我们的测试框架提供自助测试 (Self-assistant Test):通过点击测试用例列表中的某个具体用例,开发人员不需要中断测试人员的工作就可以重现缺陷。

敏捷开发中QA的职责之敏捷中的QA

QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst),主要基于以下几个方面的原因:

质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更恰当;

质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中的QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;

质量分析师更重视业务价值,关注业务价值的分析。

QA,质量分析师,显然与测试有关。敏捷中的QA,也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试,要求尽早测试、频繁测试,以及时提供反馈。敏捷测试要求团队对软件产品的质量负责,而不是某个带有QA头衔的特殊人员。 敏捷中的QA可以是参与敏捷测试的所有团队人员,而并不一定是特定的专职的测试人员。

这听起来是不是有点特别?跟传统开发模式下的测试人员是不是有些不一样?别急,我们先来看看敏捷中的QA是如何进行日常工作的。

敏捷QA的日常活动

从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示:

在这里插入图片描述

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。

在这里插入图片描述

在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。

在这里插入图片描述

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认

  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算

  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷

  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈

  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试

  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。

在这里插入图片描述

  • QA与业务分析人员结对:通常在业务分析师分析用户故事的时候,QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对,QA能够更好的理解领域知识,从而有利于定义合适的测试用例;QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。

  • QA与开发人员结对:QA和开发人员分别能给团队带来不同的技能集,认识到这一点很重要。
    作为一个团队,最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。
    通常在实现测试自动化的时候,QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高,有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分,而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。
    另一方面,QA通过与开发人员结对,编码能力也会相应有所提高,而开发人员通过与QA结对,测试意识也会增强,更有利于编写质量较高的产品代码,更有利于形成全功能团队。

  • QA与客户结对:客户是业务领域专家,通过与客户结对,QA能够更好的从终端用户的角度理解系统,从而定义或者增加更多的端到端的测试用例;
    一旦QA理解了领域知识和终端用户的观点,其业务价值分析能力会有所提高,在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段,QA通过与客户结对,帮助客户熟悉使用系统,在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同,以及敏捷测试对QA的要求有哪些。

敏捷QA与传统测试人员有何不同

我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:

传统测试人员 敏捷QA
单独的测试团队 多角色开发团队的一员
在开发流程后期才开始测试 测试贯穿于整个开发流中
通常是独立工作 QA和不同角色进行结对
被当作最后也是唯一的质量保证 关注并强调风险
缺乏与业务人员的直接沟通 和业务人员直接沟通
没有机会参与发布计划制定 参与发布计划的制定

从上表的对比可以看到,敏捷QA是特殊的,主要体现在:

  • 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。
    比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。

  • 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。

  • 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。

  • 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。

  • QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

这些特殊性对敏捷QA也提出了更高的要求,需要做到:

  • 具有丰富的产品知识和对用户业务目标的准确了解

  • 对不同系统和数据库所用到的技术知识的了解

  • 和不同角色以及客户进行有效沟通

  • 主动验证质量目标并及时说出自己的想法

  • 编写测试计划,列出需要执行的活动并进行估算

  • 自动化测试的能力和对测试工具的基本了解

  • 在团队内部进行知识分享,协助整个团队参与到测试活动中来

  • 持续提供并获取反馈

大家熟悉的测试工作(也是传统的瀑布式),是接到项目后参与需求评审,然后根据需求文档写写用例和准备脚本,等开发提测之后正式开始测试、提bug、回归,测试通过后就结束了,项目交给运维上线,之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么问题,但缺点是:

  • 测试过程是在一定时间间隔内发生的,测试人员必须等待产品完全构建才能找到错误和故障。不可否认,花费的时间超过了可以商定的时间;
  • 测试同学非常被动:当需求质量、开发质量差的时候,你只能被动接受,结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期;
  • Bug的成本在后期是非常高的,需要花费很多精力和时间去修复。甚至严重的情况是产品都不能按时发布,导致很大的损失。
  • 很有可能一个线上问题裸奔了几个月,最后是业务方先发现才排查到是Bug导致,由于影响时间过长给公司造成的损失巨大,还被质疑为什么这么明显简单的问题上线之后没人发现。
2013-02-26 16:05:50 huaer_314 阅读数 279

敏捷开发与敏捷测试

随着软件开发方法的不断演进,敏捷开发方法在各软件企业和团队中应用越来越广泛。传统的瀑布式方要求有详细的项目计划和文档,部署、QA测试和交付过程严谨。而敏捷方法的优点则体现在能够快速迭代,更多的强调人员在整个开发过程中所发挥的作用。

基于Scrum方法,TechExcel 的DevSuite产品能很好的实现敏捷开发方法,它独创混合的敏捷研发方法,实现需求、研发、测试三位一体的整合研发过程。

DevSuite是一套完整的研发过程管理软件套件,覆盖产品的概念形成、需求分析、项目规划、到任务跟踪和质量测试等全生命周期管理,帮助您有效地控制需求、资源、工期和质量,规范和改进产品研发过程,提高产品质量和工作效率。

DevSuite 其灵活、强大、易用的工作流配置和自定义能力,使之已成功应用于众多领域。

在运用DevSuite实现敏捷研发方法的同时,我们也强调敏捷测试。

QA,通常指的是质量分析/保证工程师,测试是软件质量的最后把关者、QA在敏捷团队有对质量负责的原则。

敏捷测试就是在敏捷开发模式下对软件进行的测试,要求尽早测试、频繁测试,以及时提供反馈。敏捷测试要求团队对软件产品的质量负责。

敏捷测试流程大致如下:

1. 验证需求和设计

需求和设计具体来说一般包括:

(1) 由项目经理根据需求文档而编写的功能设计文档

(2) 由开发人员根据功能文档而编写的实施设计文档。

作为测试人员,审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。

在测试初期,测试人员要学会做静态测试,做好需求分析,做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性,将自身作为第一用户积极参与项目和系统的需求分析,设计和开发。积极的参与前期工作,并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试,不要等待到功能完全做好才开始。

2. 测试计划,测试用例

2.1 编写计划,测试用例

在敏捷开发的过程中是根据user story 来分配开发任务的,当一个new feature assign story 到in development 状态去的时候,说明当前的new feature已经进入开发阶段,QA就应该根据功能设计文本开始编写对应new feature的测试用例。

2.2 测试用例的审核

当测试用例编写完毕后,QA Floater进行测试用例的审核。对覆盖率不足的地方能够及时给出意见。

在迭代后期测试要抽时间更新test case

3. 实施运行测试

在敏捷方法中,我们要求开发人员做单元测试,QA Floater做验证测试,然后才是有QA 团队进行New feature 测试流程,最后发布给客户,客户对需求的新功能进行验证和接收测试。

单元测试(开发)

在每个new feature打到QA Verification Testing之前,开发首先要根据QA Testevent 里的template进行单元测试。只有开发通过了template里的所有test points,才能打到QA Verfication Testing,由QA Floater 开始验证测试。

做单元测试的好处是可以提高newfeature质量,减少浅层次的bug发生率,使QAFloater 的验证测试能顺利的进行下去,能够将更多的精力投入到寻找深层次的bug上面。

验证测试(QA Floater)

QA Floater 的验证测试从总体上说就是将上一步设计的测试用例按照计划付诸实施的过程。

QA Floater 验证测试过程中,能第一时间的对new feature 进行测试,发现问题迅速地反馈给开发,使开发能在有效的时间内帮助修复bug。

New Feature 全面测试流程 (QA Team)

测试执行的一开始是在SQL DB上进行测试,首先针对new feature部分,之后逐步扩展将new feature 与软件现有功能结合起来,进行整合测试。

接着开始采用迭代的过程完成newfeature的整体测试,将测试划分为多个周期,分别在SQL,Oracle,MySQL等不同DB以及IE,Firefox,Chrome等不同浏览器上进行测试。

4. 软件开发末期开展fullfunction testing。

QA 全面开展测试cycle,将所有new feature 和软件现有功能整体进行系统集成测试,找出更多的bug。

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的newfeature进行验收测试、探索性测试,和开发人员结对实现测试自动化等;还要和业务人员结对分析下一个迭代的new feature,编写测试计划和测试用例

敏捷测试中的QA,是多角色开发团队的一员,测试贯穿于整个开发流程中,QA和不同的角色合作(designer,developer),及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来,在敏捷开发中体现了重要作用。

2014-08-05 09:25:06 chengying332 阅读数 539

李烨_敏捷团队中QA角色的转变


Pivotal首席软件工程师李烨参加TiD质量竞争力大会,并带来题为《敏捷团队中QA角色的转变》的主题分享。她从事软件行业11年,曾开发过Linux发行版、嵌入式终端软件、操作系统兼容性测试套件和大数据分析平台等。不仅经历过多种开发流程和团队组织形式,同时还具有多年的敏捷开发经验。


详细解读 和小伙伴们一起来吐槽

2015-05-05 18:17:27 u011790275 阅读数 1971

敏捷开发,到底需不需要 QA?”

答案是……当然是需要的。

只是期望 QA 能从传统的专注在 “流程质量”,转而与团队在一起,共同专注 “产品质量”。

所谓专注流程质量指的是:只关注团队“有没有” 搞持续集成、自动化测试、站立会议、选代演示、回顾会议,收集度量数据……等等。

所谓与团队在一起,专注产品质量指的是: 与团队在一起,从产品而非从流程的角度,只关注在团队 “应该” 做的事情上。

举个简单的例子: 团队的 Product Owner 因个人的因素考虑,而缺乏勇气去超出团队负荷的工作量时。QA 就该站在产品质量的角度,与 Product Owner 共同努力,去做应该 做的事;使团队因合理的工作量,而提升效率与质量。使团队因合理的工作量,而使版本的交付更能符合客户的预期与利益。

我曾和某企业的 QA 人员,一同到团队导入产品级敏捷的变革。

这群 QA 人员,其实自身的专业能力都已相当的扎实。但,仍十分认真的全程参与、谦卑努力的做笔记、时时的提出专业的想法与作法。

在整个导入的过程中,这群 QA 人员,与产品团队紧密的融合;引导着团队、协助 Product Owner 识别特性的重要性、管理版本需求的复杂度、与产品管理人员协商合理的工作量。

这群 QA 人员,也充分扮演好了企业内既有产品开发的流程与产品级敏捷间的桥梁;协助 Super ScrumMaster 从产品开发的视角、外部客户的视角,制定出团队内端到端的产品级敏捷开发流程框架。

别的企业(团队)也许需1-2 年才能搞定的事,这家企业(团队)因为有了这群 QA三天就搞定了;虽然,这三天大伙都累到人仰马翻。”  

虽然,未来会如何不可知? 团队最终会因产品级敏捷,发生多少正面的改变亦不可知? 但,我想,这家企业会因有这群 QA 人员,而能持续的成长,不断的改善,一直走在改革、前进的道路上。

任何人在企业的价值,是因为他能与产品在一起;QA也不例外。

产品质量就是人的质量。好的产品质量,永远只来自对的人;永远只来自对的人,有勇气,有热情,有能力的去只做应该做的事。

很遗憾的是……好的流程质量不见得会有好的产品质量;因为,流程和产品(尤其是软件)是没有绝对必然的因果关系的。

2014-05-24 05:35:41 cpongo9 阅读数 36

Diego Lo Giudice是Forrester Research的首席分析师,他在近期的博客中探讨了敏捷开发为什么领跑传统测试,他在博客中说,“敏捷实践正在打散传统的测试组织。敏捷开发人员总是要完成更多的测试,所以QA专业人员需要参与到开发团队的日常运作中。”

\u0026#xD;\n

按照Deigo所说的这种近期的趋势,QA专业人员应更加关注先进的测试实践。

\u0026#xD;\n
\u0026#xD;\n

他们需要通过深入参与这些先进的实践(比如测试驱动开发、增量的测试自动化和持续构建与集成)以适应不断变化的环境,显著地影响开发人员和测试人员的日常活动。

\u0026#xD;\n
\u0026#xD;\n

单独的测试和开发团队不适合敏捷工作环境,Deigo指出。

\u0026#xD;\n
\u0026#xD;\n

当测试团队与开发分离时,测试人员通常是去努力发现更多可能的缺陷——但前提是开发人员已经编写了代码……

\u0026#xD;\n

如果把测试人员和开发人员分开,就很难把他们的工作整合到一个持续交付流水线中。

\u0026#xD;\n
\u0026#xD;\n

挪威卑尔根市召开的2014年Booster Conference期间,关于“转变你的测试心态”的会议上,Lisa Crispin(《敏捷软件测试:测试人员与敏捷团队的实践指南》的合著者)发言了自己的意见。她的重点更多地集中在开发人员和测试人员的协作上。

\u0026#xD;\n
\u0026#xD;\n

与之截然相反……我们在此是去发现缺陷,或者确保需求得到满足,或者是对软件施以破坏

\u0026#xD;\n

想想我们如何把质量加进来?

\u0026#xD;\n
\u0026#xD;\n

Deigo还提到传统测试为什么落后于敏捷开发。

\u0026#xD;\n
  1. 大量手工的测试活动降低了交付速度。\u0026#xD;\n
  2. 团队只能在系统开发并集成完成之后才开始测试。但遗憾的是,项目经常拖期,所以团队最后只好压缩和牺牲剩下的活动。\u0026#xD;\n
  3. 团队积累了太多的技术债。按时交付有这么一个天敌,那就是在开发末期才发现你的应用中有重要的质量问题。缺陷发现得过晚会导致高返工率和巨大的浪费。\u0026#xD;\n

出于这些原因,寻求测试的转变使其遵循敏捷就极其重要了。在测试实践方面的转变也改变了开发团队挑选测试工具的方式。Deigo谈了他在测试工具方面的看法。

\u0026#xD;\n

开发人员想要的是能够轻易地嵌入到其集成开发环境(IDE)中的工具,而QA和其他软件专业人士更喜欢提供更高层次抽象,并且易于使用的工具。

\u0026#xD;\n

查看英文原文:Agile Development Races Ahead of Traditional Testing

\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n

感谢臧秀涛对本文的审校。

\u0026#xD;\n

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

敏捷开发,SIT测试

阅读数 252

没有更多推荐了,返回首页