BT

您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能。了解更多

敏捷中的QA

| 作者 林冰玉 发布于 2013年2月1日. 估计阅读时间: 不到一分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!

说到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也提出了更高的要求,需要做到:

  • 具有丰富的产品知识和对用户业务目标的准确了解
  • 对不同系统和数据库所用到的技术知识的了解
  • 和不同角色以及客户进行有效沟通
  • 主动验证质量目标并及时说出自己的想法
  • 编写测试计划,列出需要执行的活动并进行估算
  • 自动化测试的能力和对测试工具的基本了解
  • 在团队内部进行知识分享,协助整个团队参与到测试活动中来
  • 持续提供并获取反馈

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

QA和测试是两回事 by test test

不知道为什么,所有的开发人员,都喜欢把QA当成测试。
qa是质量保证,qc是质量控制,测试是tester,说测试是qc有可能,但是测试绝对和QA做完全不一样的工作。
等楼主把概念能清楚,再来写一大堆的东西吧。

QA更适合作为开发团队的软件工程咨询专家或Agile Master by Ke Tang

敏捷开发中的QA适合作为开发团队的软件工程咨询专家,或直接作为Agile Master比较好,楼主还是把QA理解为测试,要知道测试只是质量控制的其中一个环节,质量控制是控制产品结果质量,是看重结果质量,而质量保证是看你做的过程是否正确。

Re: QA和测试是两回事 by Liu cheppin

是的,QC干的是法院的活,负责断案;QA是干检查院的活,监督法院是否按照流程和规则取证、断案。

Re: QA和测试是两回事 by Li Guanglei

对术语的理解各有侧重, 本文提出的质量分析师的角色, 倒是融合了质量保证, 质量控制和测试等, 对人员的技能要求更加全面.

QA和测试 by sun wenliang

QA和测试:
QA和测试,从本质上来看,应该是两个概念。承担的工作是由区分的。QA侧重过程,以及过程上的统计分析。而测试则主要是验证功能。

Re: QA和测试是两回事 by ge lihui

我觉得现实是并没有太明显的区分,看看很多公司的QA,就知道,并非你所说的那样。
而且看文章所说的QA,也并不完全只关注于测试,这样的概念应该更趋向于QA吧。
个人认为这只是个名称问题,不用太纠结。

Re: QA和测试是两回事 by Woo Hoares

开发人员之所以喜欢把QA当成测试,是因为很多公司叫QA的人干的就是测试的活...

反对把好的东西往敏捷测试上扯,把坏的东西往传统测试上靠! by Zhu Kerry

简直是对传统软件测试的污蔑。谁说传统的测试“在开发流程后期才开始测试、通常是独立工作、被当作最后也是唯一的质量保证、缺乏与业务人员的直接沟通、没有机会参与发布计划制定“?全程测试、协作、沟通、发布、多重质量保证一个不少。2006年我就写了《全程软件测试》,在没有用敏捷测试时,我们也是从需求开始,和业务人员、产品经理沟通,时时刻刻和开发协作,从来就没什么独立工作。虽然有独立的测试部门,但在项目中,开发和测试也是密切合作的,甚至座位都特定安排开发和测试面对面坐着。也从来没有人认为测试是被当作最后也是唯一的质量保证,除非是极端落后的企业,早在上个世纪70、80年代,就提倡TQM,强调全过程的质量管理,全员都质量负责。测试人员积极参与发布计划,甚至能否发布,测试人员有较大的决定权。

没看到特殊性,缺乏创新点 by Zhu Kerry

这里提到的“这些特殊性对敏捷QA也提出了更高的要求,需要做到”:
具有丰富的产品知识和对用户业务目标的准确了解
对不同系统和数据库所用到的技术知识的了解
和不同角色以及客户进行有效沟通
主动验证质量目标并及时说出自己的想法
编写测试计划,列出需要执行的活动并进行估算
自动化测试的能力和对测试工具的基本了解
在团队内部进行知识分享,协助整个团队参与到测试活动中来
持续提供并获取反馈

良好的传统测试也都有要求,基本没什么新观点。

为什么迭代1的故事测试,要到迭代2才结束? by zeng abby

理论上讲,在每次迭代的评审之前,都应该完成本次迭代的故事测试工作。

测试工作推延,也就意味着当前迭代的部分工作(测试、Bug修复工作)的推延,即,当前迭代并没有收尾干净。

Re: QA和测试是两回事 by Zhu Kerry

比喻不恰当

Re: QA和测试是两回事 by Zhu Kerry

质量分析只是测试、QA中的一项工作,QA的内涵更深、更广,这实际是对QA不了解,才有如此新想法。

主题有偏离 by 肖 利琼

文章的主题是“敏捷中的QA”,但讨述的内容实质是敏捷中的测试,例如提到编写测试计划,自动化测试,测试工具等,难道不同公司有那么大的区别?QA与tester是有很大区别的呀,前者偏向于研发的整个流程控制,后者偏向于软件质量的生命周期把控。即使在敏捷中,它们也应有区别。再者本文的确把传统测试与敏捷测试有点对立看待了,而实际上传统的研发模式之所以大家能用那么久,是有它的适合环境的。再比如很多公司采用的半敏捷(有些人叫的小型瀑布)模式,只要能把项目做成功,也不适是一种好方法。研发模式没有万金油,合适最好。

这个QA很牛B by lee ken

www.infoq.com/resource/articles/agility-of-qa/z... 这个还是QA嘛?这个应该就是传说中的架构师吧?

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

14 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT