软件测试新趋势

2015年11月,ThoughtWorks发布了新一期的技术雷达。技术雷达是以独特的形式记录ThoughtWorks技术顾问委员会对行业产生重大影响的技术趋势 讨论的结果,为从CIO到开发人员在内的各方利益相关者提供价值。这期雷达的技术趋势主要体现在:受到热捧的微服务相关技术,逐步成熟的以Docker为典型的容器化生态系统,备受企业和用户关注的信息安全问题。本文就从这几个新趋势来分析一下给软件测试带来了哪些影响。

自动化测试是王道

在这个快速变化发展的时代,任何一款产品想要在市场具备竞争力,必须能够快速适应和应对变化,要求产品开发过程具备快速持续的高质量交付能力。而要做到快速持续的高质量交付,自动化测试将必不可少。同时,自动化测试也不是用代码或者工具替代手工测试那么简单,有了新的特点和趋势:针对不同的产品开发技术框架有着不同的自动化技术支持,针对不同的业务模式需要不同的自动化测试方案,从而使得自动化测试有着更好的可读性、更低的实现成本、更高的运行效率和更有效的覆盖率。来自技术雷达的下列主题分别体现了自动化测试的这些特点:

– 针对微服务的消费端驱动的契约测试(Consumer-driven contract testing),有助于解决随着服务增多带来集成测试效率低和不稳定的问题。消费端驱动的契约测试是成熟的微服务测试策略中核心的组成部分。

– 专门用于测试和验证RESTful服务的工具REST-assured,它是一个Java DSL,使得为基于HTTP的RESTful服务编写测试变得更加简单。REST-assured支持不同类型的REST请求,并且可以验证请求从API返回的结果。它同时提供了JSON校验机制,用于验证返回的JSON数据是符合预期的。

– 安卓系统功能测试工具Espresso,其微小的内核API隐藏了复杂的实现细节,并帮助我们写出更简洁、快速、可靠 的测试。

– ThoughtWorks开源的轻量级跨平台测试自动化工具Gauge,支持用业务语言描述测试用例,支持不同的编程语言,支持所支持平台的并行执行。

– 用于针对UI的自动化测试构建页面描述对象的Ruby库Pageify,该工具关注于更快的执行测试以及代码的可读性,并可以很好的配合Webdriver或是Capybara使用。

– 专门用于iOS应用开发的开源行为驱动开发测试框架Quick,支持Swift、Objective-C,它和用来做测试验证的Nimble捆绑发布。Quick主要用于Swift和Objective-C程序行为的验证。它和rspec和jasmine具有相同的语法风格,基础环境很容易建立。Quick良好的结构和类型断言使得测试异步程序更加容易。Quick拥有现成的Swift和Objective-C规范文件模板,开发者只需4步,即可对应用进行快速测试。

工具很重要,设计不可少!自动化测试工具云集,但做自动化也不要冲动,需要重视以下几点:

– 综合考虑项目技术栈和人员能力,采用合适的框架来实现自动化;

– 结合测试金字塔和项目具体情况,考虑合适的测试分层,如果能够在底层测试覆盖的功能点一定不要放到上层的端到端测试来覆盖;

– 自动化测试用例设计需要考虑业务价值,尽量从用户真实使用的业务流程/业务场景来设计测试用例,让自动化优先覆盖到最关键的用户场景;

– 同等看待测试代码和开发代码,让其作为产品不可分割的一部分。

自动化测试

云技术、容器化和开源工具使得测试成本下降

测试环境的准备在过去是一个比较麻烦和昂贵的事情,很多组织由于没有条件准备多个测试环境,导致测试只能在有限的环境进行,从而可能遗漏一些非常重要的缺陷,测试的成本和代价很高。随着云技术的发展,多个测试环境不再需要大量昂贵的硬件设备来支持,加上以Docker为典范的容器技术生态系统也在逐步成长和成熟,创建和复制测试环境变得简单多了,成本大大的降低。技术雷达推荐的凤凰环境(Phoenix Environment),它能够以自动化的方式支持测试、开发、UAT和灾难恢复所需的新环境准备。这一技术由上期的评估环上升到了采用环,表明它已经得到了验证和认可,是可以放心使用的技术。

另一方面是大量开源工具的出现,这些工具往往都是轻量级的、简单易用,相对于那些重量级的昂贵的测试工具更容易被人们接受。测试工作有了这些开源工具的帮助,将更加全面、真实的覆盖到要测试的平台、环境和数据,将会加快测试速度、降低测试成本;更重要的一点,有了这些工具,让测试人员能够腾出更多的时间来做测试设计和探索性测试等更有意思的事情,使得测试工作变得更加有趣。新技术雷达提到的开源工具有:Mountebank、Postman、Browsersync、Hamms、Gor和ievms等。

– 在企业级应用中,对组件进行良好的测试至关重要,尤其是对于服务的分离和自动化部署这两个关系到微服务架构 是否成功的关键因素,我们更需要更合适的工具对其进行测试。Mountebank就是一个用于组件测试的轻量级测试工具,可以被用于对 HTTP、HTTPS、SMTP和TCP进行模拟(Mock)和打桩 (Stub)。

– Postman是一个在Chrome 中使用的REST客户端插件,通过Postman,你可以创建请求并且分析服务器端返回的信息。这个工具在开发新的 API或者实现对于已有API的客户端访问代码时非常有用。Postman支持OAuth1和OAuth2,并且对于返回的 JSON和XML数据都会进行排版。通过使用Postman,你可以查看你通过Postman之前发起过的请求,并且可以非常友好的编辑测试数据去测试API在不同请求下的返回。同时,虽然我们不鼓励录屏式的测试方法,但是Postman提供了一系列的拓展允许我们将它作为跑测试的工具。

– 随着网站应用所支持设备的增多, 花在跨设备测试上的代价也在不断增大。Browsersync能够通过同步多个移动设备或桌面浏览器上的手工浏览器测试来极大的降低跨浏览器测试的代价。通过提供命令行工具以及UI界面,Browsersync对CI构建非常友好,并且能够自动化像填写表单这样的重复任务。

– 在软件开发领域,盲目地假设网络总是可靠,服务器总是能够快速并正确的响应导致了许多失败的案例。Hamms可以模拟一个行为损坏的HTTP服务器,触发一系列的失败,包括连接失败,或者响应缓慢,或者畸形的响应,从而帮助我们更优雅的测试软件在处理异常时的反应。

– Gor可以实时捕获线上HTTP请求,并在测试环境中重放这些HTTP请求,以帮助我们使用到这些产品环境数据来持续测试我们的系统。 使用它之后可以大大提高我们在产品部署,配置修改或者基础架构变化时的信心。

– 尽管IE浏览器的使用量日益萎缩,但对很多产品而言IE浏览器 的用户群依然不可忽视,浏览器兼容性仍然需要测试。这对于 喜欢使用基于Unix的操作系统进行开发的人来说还是件麻烦事。为了帮助解决这个难题,ievms提供了实用的脚本来自动设置不同的Windows虚拟机镜像来测试从IE6到Microsoft Edge的各种版本浏览器。

测试成本降低

安全测试贯穿整个生命周期

“安全是每一个人的问题”!互联网安全漏洞频繁爆发,安全问题已经成为每个产品迫切需要关注和解决的问题,安全测试将需要贯穿于软件开发的整个生命周期。同时,给软件测试人员带来了更多的机遇和挑战,要求具备更多的安全相关知识(其中还包括更多的计算机基础知识),掌握已有的安全测试相关技术,从而在软件开发的各个阶段做好安全相关的分析和测试工作。尽管有些团队已经将安全跟整个开发实践结合起来,但培养每个人在每个阶段的安全意识还相当的重要,探索新的安全测试技术、方法还有很多空间。

安全测试贯穿软件生命周期

技术雷达上列出的安全测试相关的技术和工具有:Bug bounties、威胁建模(Threat Modelling)、ZAP和Sleepy Puppy。

– Bug bounties是一个安全漏洞举报奖励制度,越来越多的组织开始通过Bug bounties鼓励记录常见的安全相关的Bugs,帮助提高软件质量。

– 威胁建模(Thread modeling)是一组技术,主要从防御的角度出发,帮助理解和识别潜在的威胁。当把用户故事变为“邪恶用户故事”时,这样的做法可给予团队一个可控且高效的方法使他们的系统更加安全。

– ZED Attack Proxy (ZAP)是一个OWASP的项目,允许你以自动化的方式探测已有站点的安全漏洞。可以用来做定期的安全测试,或者集成到CD的Pipleline中提供一个持续的常规安全漏洞检测。使用ZAP这样的工具并不能替换掉对安全的仔细思考或者其他的系统测试,但是作为一个保证我们的系统更安全的工具,还是很值得添加到你的工具集里。

– Sleepy Puppy是Netflix公司近期开源的一款盲打XSS收集框架。当攻击者试图入侵第二层系统时,这个框架可用于测试目标程序的XSS漏洞。XSS是OWASP的Top10的安全威胁,Sleepy Puppy可以用来同时为几个应用完成自动安全扫描。它可以自定义盲打方式,简化了捕获,管理和跟踪XSS漏洞的过程。Sleepy Puppy还提供了API供ZAP之类的漏洞扫描工具集成,从而支持自动化安全扫描。

优化业务价值

大多数软件都是做项目的模式,在不同的档期内进行计划、实现和交付。敏捷开发极大的挑战了这种模式,通过在开发过程中各个阶段进行的分析和测试工作,持续的发现新的需求,使得需求更趋于合理化,更能体现业务价值。精益创业的技术,如观察需求的A/B测试,进一步削弱了这种心态。技术雷达推荐“产品优于项目(Product over project)”,认为大多数的软件开发工作应该遵循精益企业的引领,将自己定义为构建支持业务流程的产品。这样的产品并没有所谓的最终交付,更多的是一个探索如何更好的支持和优化业务流程的过程,只要业务依然有价值就会不断持续下去。

作为软件开发中的关键角色、负责软件测试的QA人员,通过从用户角度对软件的测试,结合自身对软件产品的了解,对优化业务价值将会起到举足轻重的作用。软件测试不仅是检验软件是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程,还需要有意识的对需求进行持续的验证和优化,对业务的趋势和风险进行分析。如果能在开发过程中结合使用BDD(行为驱动开发)的思想,统一团队对需求的认识,利用团队的力量来优化业务将会达到事半功倍的效果。

传统方式下,QA的角色主要专注于保证软件产品在类产品环境下的质量。随着持续交付的出现,QA的角色逐渐转变到需要分析软件产品在产品环境下的质量。产品环境下的QA(QA in production),就是要求QA角色在做好产品上线前的质量保证工作前提下,做好软件产品在产品环境下的质量分析。具体做法有:

(一)引入产品系统的监控, 制定检测条件,找出产品环境下使用的质量度量。比如,利用网站分析工具收集用户使用应用程序的数据,分析数据量需求、产品的性能趋势、用户的地域特征、用户的行为习惯和产品在同类型产品市场的占有率等。

(二)收集产品环境下最终用户的反馈,对反馈进行分类分析。这些反馈可能有:

– 缺陷:需要进行优先级划分,确定是否需要修复;并且对这些缺陷进行根源分析,在以后的开发过程中尽量避免同类型的缺陷再次出现。

– 抱怨:对于抱怨需要分析其背后的原因,可能正是能够帮助我们改进和优化业务价值的好机会。

– 建议:一般用户可能难以提出高质量的建议,需要我们在收集反馈的时候下点功夫,有针对性的去收集。一旦收集到了建议,将是对业务价值优化非常有利的。

通过对产品环境下的软件质量进行分析,将有利于协助“产品优于项目”实践,帮助优化业务价值,做好企业产品的创新工作。需要注意的是,产品环境下的QA可能会导致有些组织走的太远而忽视产品上线前的质量保证,它只对那些已经执行并有一定程度持续交付实践的组织有价值。

总结

软件测试是一项技术工作,但软件测试领域的问题不仅仅是技术问题。随着自动化程度越来越高,不断有人怀疑QA存在的必要性,从前面的分析可以看到,新趋势给QA提出了更高的要求,带来了更多的机遇和挑战,相信好的QA是不可能简单的被取代的。

(此文发表于TW洞见InfoQ

软件缺陷的有效管理

“这次发布之前怎么这么多的缺陷,是不是需要分析一下啊?” 答案是肯定的,可是这个时候才想起要分析已经有点晚了,有可能这些缺陷很难分析了。这是发生过的一个真实场景,所记录的缺陷包含信息很有限,很难有效的做好分析!本文就来聊聊如何有效的管理和分析缺陷。

缺陷记录

曾经有个项目是在QC(Quality Center)里记录缺陷,需要填写很多必填属性字段,加上QC服务器在国外,访问速度非常的慢,每次记录缺陷成为了大家极其痛苦的一件事情。于是,很多时候,发现了缺陷也不愿意往QC里填,而是直接写个纸条简单记录下,验证完了它的生命周期就结束了,这样后面就没办法去很好的跟踪和分析了。(题外话:当时采用脚本稍微减轻了点痛苦。)

也有的项目对缺陷的格式和属性没有严格要求,记录的时候很简单也很自由,这样记录的缺陷由于很多必要信息的缺失,对后续的跟踪和分析也是极为不利。

还有一种情况就是记录缺陷时同样有一些属性要求填写,但是这些属性值可能不是那么有意义,导致存储的信息不仅没用,反而添加混乱,也是不利于跟踪和分析的。比如,其中的“根源(root cause)”属性的值如下图1所示,这些值根本就不是根源,这是一个没有意义的捣乱属性。

图1.某项目缺陷根源属性值

缺陷记录应该做到尽量简单,且包含必要的信息。

1. 标题:言简意赅,总结性的语句描述是什么缺陷

2. 详情:包括重现步骤、实际行为、期望结果等,根据具体情况确定其详细程度,必要时可以添加截图、日志信息等附加说明。

3. 重要属性:优先级、严重性、所属功能模块、平台(OS、浏览器、移动设备的不同型号等)、环境、根源等,这些属性对应的值需要根据不同项目的情况自己定义,其中“根源”是相当关键的一个属性,后面有示例可以参考该属性对应的值有哪些。

4. 其他:每个项目对应的还会有其他信息需要记录的,自行定义就好。

在敏捷开发环境中,测试人员可能随时在测试、随时都会发现缺陷,包括还在开发手里没有完成的功能。什么时候发现的缺陷需要记录呢?通常情况下,开发还没完成的用户故事(story),测试人员发现缺陷只需要告诉开发修了,在该故事验收的时候一起检查就好了,无需单独记录;在开发已经完成,交到测试人员手里正式测试的故事,再发现缺陷就需要记录来跟踪了;后续的所有阶段发现的缺陷都需要记录。

缺陷分析

比较推荐的一种缺陷分析方法是鱼骨图分析法,可以将跟缺陷相关的各个因素填写到鱼骨图里,对缺陷进行分析,如下图2示:

图2. 鱼骨图缺陷分析法

缺陷相关的各属性拿到了,就可以用表格、曲线图、饼图等统计各个属性对应的缺陷数量,分析缺陷的趋势和原因。下面是我在项目上做过的分析报告图:

图3. 功能/环境对应缺陷数量统计表和缺陷根源比例图

图4. 缺陷根源统计表和比例图

图5. 缺陷迭代趋势分析图

分析完得到统计的结果就要采取对应的措施,从而防范更多的缺陷产生。比如:修缺陷(上面示例中的“bug fixing”)引入的新缺陷比较多,可以在修复缺陷后添加对应的自动化测试;浏览器兼容性问题相关的缺陷较多的话,可以在开发完成验收的时候在多种浏览器上验收,等等。

什么时候该进行缺陷的分析呢?通常,推荐每个迭代周期分析一次,并且跟以往各个迭代进行对比,进行趋势对比。当然,有时候可能一个迭代发现的缺陷非常少,分析的周期可以根据具体情况做出调整。

总结

缺陷记录是为更好的跟踪和分析缺陷做准备的,而缺陷分析是软件质量保证的重要环节,对于软件过程的改进,软件产品的发布来说具有十分重要的参考价值,建议各项目定期都要做做缺陷分析。

(此文发表于TW洞见

说起BDD,你会想到什么?

在刚接触BDD(Behavior Driven Development,行为驱动开发)的时候,我以为就是用Cucumber这样的工具来编写场景用例,从而实现自动化测试,甚至很长时间分不清BDD和ATDD(Acceptance test driven development)到底有什么区别。那么,BDD真的就是用来做自动化测试的吗?本文就来跟大家分享一下我理解的BDD。

BDD

为什么要BDD?

“开发软件系统最困难的部分就是准确说明开发什么” (“The hardest single part of building a software system is deciding precisely what to build” — No Silver Bullet, Fred Brooks) 。

场景一:业务分析人员觉得自己分析的需求已经写的很清晰了,并且跟技术人员进行了足够的沟通,可是开发完做Desk check的时候,发现所开发的功能还是跟期望有差距。
场景二:开发团队辛辛苦苦开发完一个功能,满怀信心的去给产品经理/客户展示的时候,才发现原来客户需求的功能不是这样的。

这些场景是不是似曾相识?为什么会这样?第一个场景是开发团队内部技术人员跟需求分析人员的理解有偏差,导致大家理解的需求其实是不一样的;第二个场景是开发团队没有真正理解产品经理/客户所提出来的真实需求,导致开发的产品跟需求不一致。其实,产生这两个不一致的真正原因是因为不同角色有着不同的领域知识,说着不同的语言,大家在沟通的时候,如果都用自己领域语言,必然会产生沟通代沟,导致理解的不一致性。

领域知识不同、语言不通导致沟通障碍,这个客观存在的问题该如何解决呢?BDD正是为此而生。

BDD是什么?

BDD的提出者Dan North强调BDD不是关于测试的,它是在应用程序存在之前,写出用例与期望,从而描述应用程序的行为,并且促使在项目中的人们彼此互相沟通。

要给BDD下个清晰易懂的定义很难,包括大师们也这么认为,这里试着总结以下几点:

1. 关注的是业务领域,而不是技术:BDD强调用领域特定语言(DSL, domain specific language)描述用户行为,定义业务需求,而不会关心系统的技术实现。
2. 不是工具,强调的是一种协作方式:BDD要求各个角色共同参与系统行为的挖掘和定义,以实现对业务价值的一致理解。
3. 不是关于测试的:BDD源自TDD,又不同于TDD,重点不是关于测试的,但可以指导更好的做自动化测试。
4. 全栈敏捷方法:BDD促使团队所有角色从需求到最后的测试验证,进行高度的协作和沟通,以交付最有价值的功能。

BDD怎么做?

用例场景的描述格式“GIVEN… WHEN… THEN… ”对大家都不陌生,但用这个格式写出好的用例却是非常的难,尤其是新手。这里总结几点供大家参考:

1.业务层抽取,业务语言描述

根据业务层的数据流,在每个数据停留点进行纵切,抽取出一个个用例场景。描述语言一定是业务领域可懂的,不要涉及任何实现相关的技术细节。所描述的场景一定是从业务层抽象出来,体现真实业务价值的。

2.技术人员可懂,自动化友好

所描述的用例场景要能驱动开发,必须要让技术人员易于理解;要指导自动化测试,还得要求对于自动化的实现是友好的。这一点似乎是跟第一点有些矛盾,但我们严格遵守BDD的格式要求还是可以做到的。其中,GIVEN从句描述的是场景的前提条件、初始状态,通常是一种现在完成时态;WHEN从句是采取某个动作或者是发生某个事件,一定是动词,通常是一般现在时;THEN从句用“应该…(should be…)”来描述一种期望的结果,而不用断言(assert),后者与测试关联更紧密。

3.数据驱动,需求实例化

抽象的业务语言描述的需求,往往由于太抽象而缺失掉很多关键信息,导致不同人员对需求理解的不一致。想要既抽象又能包含细节信息,就需要采用需求实例来描述。简单说来,就是给场景用例举例说明。举例就会需要列举数据,如果在场景用例描述里边直接添加数据实例,那样的用例将会很混乱,可读性和可维护性都非常差。如果我们能够在描述场景的用例里边用一些变量来代替,把变量对应的值(数据)提取出来存为一个表格或者独立的文件,这样将会使得用例的可读性很好,而且也不会缺失细节信息(数据),后期的维护和修改也较为方便。这就是数据驱动的方法来描述实例化的需求。

下面举几个例子,大家体会一下:

场景一:检查收件箱,可以看出第三个清晰明了且能体现业务价值,比较符合上面的要求。

场景二:限制非法用户查看某些受限内容,BDD要强调什么(What),而不是怎么(How),第二个写的比较好。

场景三:添加图书到购物车并计算总额

BDD的工具有Cucumber、JBehave、Twist、Concordion等,工具的优缺点和使用方法,网上都有丰富的文档可参考,在此不作介绍。

BDD有什么好处?

BDD的作用是把利益关系人、交付团队等不同方面的项目相关人员集中到一起,形成共同的理解,共同的价值观以及共同的期望值。它可以帮助我们:

1. 关注用户行为

2.交付最有用的功能

3. 在团队内部维护一致的术语

4. 探究需求实例

5. 编写和维护需求

6. 创建活的文档

7. 消除协作与沟通障碍

什么样的项目适合BDD?

简单的一次性项目,沟通交流成本都较低的情况下,没有必要使用BDD;

业务比较轻量,重在技术方面的项目,可以使用简单的白板上的BDD,不需要在BDD工具记录需求用例文档;

业务复杂、团队成员较多的项目,沟通成本高,BDD很有必要。

常见疑惑

1.BDD与TDD/ATDD

TDD是测试驱动开发,ATDD是验收测试驱动开发,都是关于测试的,是与所开发的系统紧密联系的。而BDD则不同,前面提到过BDD不是关于测试的,着重关注需求、关注客户的业务价值,所描述的需求用例是可以独立于软件系统存在的,因为客户的业务是始终存在的,不取决于是否有软件系统来支撑。

2. BDD与SBE

SBE(Specification By Example,实例化需求)是在BDD之后由Gojko提出来的,也是关于需求的,主要强调通过列举实例发现需求中的缺失概念。BDD也是关注需求的,同样会使用实例来描述行为。两者的本质没有区别,只是概念的差异。

(此文发表于TW洞见

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

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

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

与传统QA的对比

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

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

  • 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。
  • 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。
  • 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。
  • 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。
  • QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

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

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

(该文发表于InfoQTW洞见