敏捷软件测试常见的七个误区

敏捷软件开发是从1990年代开始逐渐引起广泛关注的一种新型软件开发方法,是能够应对快速变化的需求的一种软件开发能力,它作为一种新型的开发模式,被越来越多地应用到软件项目中。

敏捷软件测试指的是在敏捷软件开发过程中跟质量相关的一系列活动,和传统意义上的软件测试有很多区别,因为敏捷软件测试的概念一直比较模糊,所以经常会有人走入误区,我曾经在瀑布型的软件开发模式下做过几年的测试人员,所以在刚刚接触敏捷项目的时候也曾有过一些误解,但是在敏捷软件开发团队工作将近5年后,对很多问题有了新的认识,以下针对几个常见的误区和大家分享一下我的理解。

不需要测试策略

测试策略关注的是目标和方法,即怎样在限定的时间内有效利用有限的资源达到提前制定的目标,一般制定测试策略时会首先明确测试目标,然后确定需要哪些测试类型,各种测试类型所占的大概比例,选择测试框架,最后规划一下软件发布前需要经历哪些测试阶段。

很多人认为,敏捷软件开发以用户故事为单元,是不是集中精力在用户故事测试就足够了?是不是根本不需要考虑测试策略?

其实这是一个很大的误解,因为敏捷软件开发通常都是迭代式的发布,周期比较短,资源非常有限,这就更需要我们统筹规划,小到一个用户故事,大到一个完整的用户特性,都需要考虑怎么合理利用测试资源,所以敏捷项目是非常需要测试策略的。

具体到实际项目中,通常团队会在项目初期(迭代0)制定测试策略,明确目标(包括功能性需求的目标以及非功能性需求的目标),然后确定在开发阶段需要添加哪些自动化测试(包括单元测试,接口测试,契约测试,集成测试,系统级别的UI的用户场景测试),并规定这些测试的大概比率(符合测试金字塔),选择自动化测试框架(比如XUnit)以及需要哪些手动测试(包括探索性测试,可用性测试等),还要规划每个发布周期需要进行的测试阶段(比如新功能测试,回归测试等),之后测试策略会对敏捷团队的开发及测试起到非常重要的指导作用,当然,每个团队因为项目的不同策略也会不同。

下图就是一个简单的敏捷测试策略介绍:

1

不需要测试文档

测试文档通常包括测试计划,测试用例,测试报告,测试缺陷等文档以及相对应的可以指导测试的一部分需求文档。

很多人会认为,敏捷软件测试是不需要文档的,敏捷宣言中有一句“工作的软件 高于 详尽的文档”,尽管敏捷宣言最后提到了“右项也有价值,我们更重视左项的价值”,但人们往往会忽视右项的内容,导致在很多刚开始实施敏捷开发的团队中完全否定了测试文档的作用。

首先不可否认,在实际的敏捷项目中,确实很少见传统意义上的正式的专门的需求文档和测试文档,但这并不代表敏捷项目没有文档,比如用户故事本身就是需求的载体,用户故事中的验收条件就是敏捷测试文档的一部分, 另外很多敏捷软件项目都会采用BDD的方式进行开发,将测试用例用业务人员能够看懂的自然语言描述,并结合自动化实现,形成一个融需求和测试为一体的文档,而且为了应对敏捷软件测试变化快文档更新不及时导致的问题,很多敏捷项目都在使用Living document

3

纯自动化测试 or 纯手动测试

有些刚接触敏捷的人认为敏捷软件开发发布周期很短, 测试人员根本没有时间做手动测试, 所以应该采用纯自动化测试。

也有一些人认为,敏捷开发强调快速响应变化,如果投入成本在自动化测试上,那么肯定会导致维护自动化测试带来的资源浪费,所以应该采用纯手动测试。

这是两种极端的误解,虽然这两种观点所考虑到的难点确实存在, 因为在敏捷软件开发过程中, 迭代通常比较短,确实不会预留足够多的时间来做手动测试, 所以必须要有足够多的自动化测试来保障。

然而因为测试代码本身可能存在缺陷,而且有很多部分难以被自动化测试覆盖(比如界面的测试,可用性测试,探索性测试等),所以敏捷测试也同样离不开手动测试。

至于关于自动化测试维护成本的顾虑,敏捷项目也确实存在变化比较多的特点,但通常变的都是比较接近用户的部分,所以应该尽量减少用户级别的依赖界面的自动化测试,而多增加一些不容易变化的底层的单元测试接口测试等。

推荐敏捷测试以自动化测试为主,手动测试为辅。

2

敏捷QA = 敏捷Tester

在很多刚接触敏捷实践的团队中,大家对敏捷QA的认识还停留在Tester的阶段,认为只要用户故事开发完成之后,QA去专职地做测试,发现缺陷就够了。

这是一个很大的误解,首先QA(Quality Assurance/Analyst),不是单纯意义的测试人员,通过这个角色的名称我们可以看的出来敏捷QA强调的是质量保障和分析,而不单纯是测试产品。

在实际的项目中,敏捷QA通常会从需求分析阶段就开始参与整个软件开发过程,通过在不同阶段和团队中的不同角色合作,帮助整个团队对质量达成共识,并通过在不同阶段的确认和验证做到缺陷预防,而不是等到软件开发完成后再去发现缺陷,所以对于敏捷QA来说,其目标是软件开发完成后能够发现的缺陷越少越好,而对于Tester来说,发现越多的缺陷证明工作做得越优秀。

4

非功能性测试不重要

非功能性测试指的是针对非功能性需求(软件本身满足用户需求所必需的功能性需求以外的一些特性,比如安全,性能,可用性,兼容性等)的测试,通常包括安全测试,性能测试,可用性测试,兼容性测试等。

在敏捷软件项目中,需求被切割成了很小的单元,在切割的过程中,非功能性需求是最容易被人忽略的一部分,而这导致的问题就是非功能性测试经常被团队忽略,久而久之,就会形成这样一个误解,认为非功能性测试是不重要的。

这个观点非常不对,首先非功能性测试的重要性并不会因为软件开发模式的不同而有所不同,尤其安全测试和性能测试的重要性正越来越多地被重视起来,因为很多产品必须考虑到用户敏感信息的安全以及性能导致的用户满意度,在敏捷项目中由于软件会尽早发布,如果这些非功能性需求出现问题,就会更早地造成影响,很可能在软件刚步入市场就损失掉大多数的用户。

所以非功能性的测试和功能性测试同等重要,在实际的项目中,比较好的做法是将这些非功能性需求也加入到用户故事的验收条件中,在整个敏捷开发流程中对这些非功能性需求进行验证。

5

质量是QA的事儿

受传统观念的影响,很多人还是会认为质量是QA的事儿,如果产品发布后质量不好是QA的问题,其他角色和质量没有太大的关系。

首先这种认识太高估了QA对质量的作用,软件的质量是在软件开发过程中逐步形成的, 从需求分析阶段是否真正的了解到了客户想要的功能,到开发阶段是否增加了足够多的自动化测试保障,是否写了足够健壮的产品代码,到最后测试阶段是否测试了功能引入后整个系统的可用性,不同用户路径是否能正常工作等等,这些都是软件质量的组成部分。

可以看得出来,在整个过程中,软件的质量离不开敏捷团队各种角色的付出,其中有业务分析人员对需求的准确把握,有开发人员对产品代码的高标准实现,对自动化测试覆盖率的保障,还有QA在整个过程中对质量相关活动的实施和保障,包括需求分析阶段从QA的视角对业务的补充,开发阶段对自动化测试的审查,以及探索性测试可用性测试等对产品质量的进一步保障。

所以在敏捷测试中更多时候我们会淡化角色的概念,强调团队人人都为质量负责,这样更有助于团队的每一位成员都把质量作为非常重要的一部分,而不是依赖于某个人或者某个角色。

6

开发可以写测试,不再需要QA了

因为敏捷团队强调人人都为质量负责,开发人员会采用TDD等方式写大量的自动化测试,那么是不是就不需要QA了?

对于这个观点,在社区有过很多激烈的讨论,比如这篇文章《我们需要专职的QA吗?》就曾经引起了很大的争议,其实个人认为这篇文章里提到的QA指的是Tester,具体两者的区别可参考前面的观点;抛开这个,作者的某些观点其实是很有价值的,比如作者最后提到了质量不是测出来的,要通过软件生命周期各个阶段相关活动的保障,而这些活动都离不开QA的参与。

首先需求分析阶段,QA可以从不同的视角对于需求提出疑问,补充,修改,因为QA特有的技术背景,对于软件的可用性等有更深入的理解,所以往往可以提出不同于业务分析师和开发人员的观点;开发阶段,QA也会审查开发人员写的自动化测试,通过QA的专业测试背景帮助开发人员写更有价值的测试,比如我们在项目中曾经发现开发人员写了很多没有业务价值的测试;测试阶段,探索性测试,可用性测试,安全测试,性能测试等都是QA们在做的事情。

当然,如果业务分析师从各种视角把业务分析的透彻完美,开发人员可以写非常有价值的测试,也可以做各种类型的手动测试,那么去掉专职QA也不是不可以,那样的话不是不需要QA,而是人人都是QA。

7

结论

以上列出来的七点是刚刚接触敏捷测试时很容易进入的误区,甚至有的观点在一些已经施行敏捷很长时间的团队中仍然存在,这些观点很容易导致敏捷测试走上弯路,以上是结合实际项目经验个人的一些思考,希望对大家有所帮助。

Share

敏捷中的QA

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

  • 质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更恰当;
  • 质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中的QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;
  • 质量分析师更重视业务价值,关注业务价值的分析。

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

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

敏捷QA的日常活动

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

1

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

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

3

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认
  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算
  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷
  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈
  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试
  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

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

4

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

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

本文转载自:http://www.infoq.com/cn/articles/agility-of-qa

Share