2017-05-18 09:08:28 huver2007 阅读数 6768



敏捷开发中QA如何做质量管理?

经常有人会问我,敏捷模式下,QA的职责是什么?QA有什么价值?我们还需要QA吗?敏捷转型中遇到的问题,QA能帮助解决吗?这些问题以前也思考过,笔者就是QA出身的,曾经在中兴通讯做过两年多的PQA,在中兴通讯的敏捷转型中也遇到过这些问题。

先总结一下敏捷转型中遇到的问题吧,QA的工作也是要围绕这些问题展开的:

  1. 很多公司希望采用敏捷,但是又没有把握

  2. 传统的瀑布式开发流程在公司已根深蒂固,虽无法满足快速发展的需要,但大规模改动又不现实,老板也不愿意花太多的成本

  3. 缺少敏捷软件开发专家和人才

  4. 研发人员需要观念的转变和方法培训

  5. 缺乏相应的质量控制方法

  6. 需要经常的和及时的质量度量

  7. 自动化测试不能落到实处,持续集成发挥不出作用

  8. 人员水平参差不齐,有人支持有人反对

笔者也先后参加过多次华为、腾讯、平安科技等公司的敏捷推行者的分享活动,也参加过Thoughtwork、康仕诚、ScrumCN等专业机构的培训,对国内敏捷项目的质量管理有一些想法,结合笔者这几年的质量管理经验,总结一下:

1)QA角色的转变

QA以往主要还是作为警察的角色,从事各种审核活动,要从警察转变成教练。传统项目里,QA习惯拿着事先准备好的检查单,对项目一条条做审核,发现问题开不符合报告,给团队的感觉就是一个监工。虽然笔者自己也不喜欢人家这么说我,但确实我们给项目成员你的印象就是监督。

中兴通讯从2014年开始,各研究院都大力推行敏捷转型,刚开始觉得有点失落,都敏捷了,都不知道该怎么下手了,审核不能叫审核,要叫观察,审核报告也要叫观察记录。经过几个月基本上适应了,QA、项目管理员都往敏捷教练的方向上转,在外界专业教练的指导下,引导项目开展各类敏捷活动。

比如该如何开站立会议,该怎么去做迭代的计划等等指导性的工作,不过以前的项目团队划分成十多个特性团队,一个人要跟十几个PO、SM打交道,对于QA的沟通能力增加很多,每天奔赴各个团队。

2)QA参与各项活动,如需求梳理会、计划会、早会、持续集成看板、演示、回顾会等,各项持续集成结果也都推送到QA,这样便于及时获取团队的信息,也便于QA输出各类观察记录、报告。

3)自动化回归测试。敏捷团队没有自动化会成功吗?可能也会成功,但我们所知道的成功团队都依赖于自动化回归测试,如腾讯和支付宝公司的Selenium框架,阿里巴巴和淘宝网的QTP框架。笔者咨询认为,敏捷开发利用测试来指导开发,为了编写的代码使测试通过,需要快速而简单地运行测试,没有短期反馈周期和安全的回归测试,团队将很快陷入技术债务,缺陷不断增加,速度越来越慢。

4)提供并获取反馈

反馈是敏捷的核心价值,敏捷的短期迭代可以提供持续的反馈以帮助团队正常运转,测试人员则通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供支馈。如你怎么知道客户手里拿到了预期行为的正确示例?你怎么知道编写的测试用例正确地反映了这些示例?开发人员通过查看测试用例能够理解应该编写什么代码吗?QA和测试人员应该询问开发人员是否得到了足够的信息以理解需求并是否能够指导编码,询问客户是否理解质量标准,应花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。

5)构造核心的敏捷实践活动

软件行业有一句老话是:软件质量是设计出来的。对于敏捷开发也是如此,笔者认为没有一些基础的实践活动,无法产生出高质量的软件。

  1. 持续集成:持续集成(CI)是一项软件开发实践,其中团队的成员经常集成他们的工作,通常每人每天至少集成一次,每次集成通过自动化构建完成。利用持续集成可以让缺陷在引入的当天就被发现并解决,降低缺陷修改成本;将集成工作分散在平时,通过每天生成可部署的软件;避免产品最终集成时爆发大量问题。QA可以关注这些持续集成发现的问题分布情况、解决情况、构建周期,及时度量出相关数据。

  2. 看板:最便宜的敏捷工具,可实现价值流、可视化、拉动、限制在制品、找出瓶颈等多个作用。用户故事可以用看板,QA自己的任务同样可以用看板管起来,便于QA之间互相沟通、对齐信息。

  3. 自动化测试:持续集成的前提是有自动化测试用例,以及代码静态检查、代码行覆盖率、代码复杂度等各种工具,如果这些没做起来,只是持续构建,并没有太大意义。自动化测试属于防御性测试,把所有的质量风险用穷举法列出测试用例,然后测试用例提前写好,然后写代码帮你执行,预防缺陷的泄露。但是成本同样非常大,是否能推行起来,就看领导的魄力了。

  4. 每日晨会:每个团队每天大概花15-30分钟,回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作(特点:是站着开会)。一般主持人由敏捷团队的成员轮流担任,这个时候可以了解每天发生的问题。QA可以参加晨会,根据自己的观察提出问题。

  5. 结对编程:两位程序员在一台电脑前工作,一个负责敲入代码,而另外一个实时检视每一行敲入的代码;操作键盘和鼠标的程序员被称为“驾驶员”,负责实时评审和协助的程序员被称为“领航员”;领航员检视的同时还必须负责考虑下一步的工作方向,比如可能出现的问题以及改进等。有助于提升代码设计质量;研究表明结对生产率比两个单人总和低15%,但缺陷数少15%,考虑修改缺陷工作量和时间都比初始编程大几倍,所以结对编程总体效率更高,同时结对编程能够大幅促进团队能力提升和知识传播。不过这个实践也是最难推行的,往往只有进度不紧的时候才会尝试。

  6. 用户故事:用户故事是站在用户角度描述需求的一种方式;每个用户故事须有对应的验收测试用例;用户故事是分层分级的,在使用过程中逐步分解细化;典型的描述句式为:作为一个XXX客户角色,我需要XXX功能,带来XXX好处。用户故事的好处是:用户故事站在用户视角便于和客户交流,准确描述客户需求;用户故事可独立交付单元、规模小,适于迭代开发,以获得用户快速反馈;用户故事强调编写验收测试用例作为验收标准,能促使需求分析人员准确把握需求,牵引开发人员避免过度设计。QA可以引导项目团队如何编写用户故事、验收标准。

  7. 迭代回顾会议:在每轮迭代结束后举行的会议,目的是分享好的经验和发现改进点,促进团队不断进步。会议需要Team全员参加,气氛宽松自由,畅所欲言,头脑风暴发现问题,共同分析根因;会议关注重点是Team共同讨论优先级,将精力放在最需要的地方(关注几个改进就够了);会议结论要跟踪闭环。QA同样可以参加回顾会议,引导团队如何召开,并跟踪改进事项。

总之,笔者认为,质量是整个敏捷团队的职责,团队中的每一个人都应该关注手边的一个任务或者故事,敏捷模式下的质量管理更具有挑战性,但与传统瀑布模式相比,其在应对需求变化、提升产品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具有明显优势。敏捷的焦点在于交付有价值的软件,一直到客户满意为止。在这个“快鱼吃慢鱼”时代,要想交付好而快的产品,不防用敏捷模式试试。

(为偷懒,本文有些内容为网上抄袭)



2012-06-01 11:26:02 kaka1121 阅读数 3150

-- Main.yangyang - 2012-05-07

敏捷开发,QA面临的10个挑战


敏捷开发,QA面临的10个挑战

1.没有MRD,如何管理好需求?
2.没有需求评审,怎么保证需求质量?
3.研发模式变更,怎么把握进度?
4.没有详细设计如何保证设计没有问题?
5.没有测试设计如何保证测试质量?
6.何时提测?提测频繁,如何降低提测成本?提测时间不固定,如何分工?
7.如何提高RD代码质量?
8.没有准入,怎么保证提测质量?
9.如何避免新增story影响已有功能造成质量问题?
10.上线频繁,如何降低上线的成本?

 

1.没有MRD,如何管理好需求?

(1)使用story模式来管理需求,将庞大的MRD划分为一个个合适粒度,且可独立交付的story(通常每个story能在1~5天内完成,包括设计、开发、测试),需求清晰明了,易达成一致,且可节省大量的需求评审时间。

(2)要求PM在第i个迭代上线前一天,完成所有第i+1迭代的需求拆分,和RD、QA达成理解一致,且辅助QA一起补充完验收标准,在第i个迭代启动前完成所有story的相关工作。

(3)每个story都有自己的优先级、估点(即预计花费时间),以此为依据判断是否纳入某迭代。

(4)PM随时待命,快速响应,答疑解惑、修改设计不足。


2.没有需求评审,怎么保证需求质量?

challenge:需求不评审了?开发时遇到一堆问题怎么办?测试时发现一堆问题怎么办?作为质量的监督者,QA面临着很大的冲击和挑战


虽然没有需求评审会议,但每个story都是经过仔细推敲和沟通过的

(1)首先,一个story被PM提出时,需写好用户故事卡片和详细描述;

(2)接着,PM会找RD、QA的leader进行讲解,并交review,review人提出问题及改进意见;

(3)然后,PM和负责具体开发RD、测试QA进行讲解和讨论,RD、QA提出问题、疑问,PM解答,并对详细描述进行修改。

(4)最后,所有参与者觉得没有问题后,PM辅助QA补充详细的验收标准,RD对其进行review,并作为自测和自动化case编写的参考。

(5)此外,在开发和测试的过程中,若发现新问题,PM随时响应,答疑解惑,修改设计的不足。

上述每一个步骤都被落实后,不仅需求质量被保证了,QA也成了需求管理的核心。即使有未考虑到的问题,敏捷团队也能够很快消化,在下个迭代迅速优化。


3.研发模式变更,怎么把握进度?

challenge:没有详设计划?没有开发计划?什么,连测试计划都木有?QA怎么保证项目保质保量按时上线?


(1)定期发布

定期发布上线,把整个项目划分为一个个迭代,每个迭代时间大小固定,迭代结束时上线交付一次。


(2)迭代规划

迭代规划相当于整个迭代的计划,帮助我们管理并保证每个迭代的交付。

A.迭代规划的前提:


story沟通及验收条件的补充完成。

PM给出story的优先级

RD、QA给出story的估点,估点可取范围为(1、2、3、5),若有大于等于5点的story,尽量拆分成更小的story。

B.迭代规划

估算团队交付能力(通常经历几个迭代,团队的交付能力就会很明了了):基于“昨天的天气”(很可能他们在当前迭代完成的工作量与上一个迭代相同,除非工作环境或是团队构成发生重大变化)和常识,估算自己能够在当前迭代中完成多少工作。然后团队就会基于自己的工作交付能力,选择当前迭代要开发的工作。

有了团队交付能力值,便进行以下步骤安排本迭代的工作:


  1. 按照优先级顺序,列出story,并注明它们的故事点数大小。
  2. 判断一个迭代中可以交付多少故事点数。
  3. 考虑团队需要完成的非用户故事工作可能产生的影响,比如在早期的迭代中,由于工具和工作环境不到位,工作效率会受到影响。
  4. 向计划中加入一个新的迭代。
  5. 向迭代中加入故事,直到用掉所有的工作能力。
  6. 询问:是否所有的故事都已经解决、版本发布目标是否达成。
  7. 如果没有,那么向计划中加入新的迭代,并重复步骤5和步骤6.
  8. 一旦所有的故事都已经分配完成,与大家就计划进行交流,并征求他们的反馈,看看这些计划是否现实并且可以完成。

PS:通常只会进行到第五步,剩余的stroy放入需求池,下个迭代启动时再规划。

(3)每日站会

站会的目的有三个:

(1)周知进度

从用户故事和任务的层面周知进度,任务进度只有两种状态:完成未完成(完成百分比)。

(2)周知计划

你将会在下次会议之前做哪些工作?

(3)抛出问题

哪些东西阻碍你的进度?(“没有问题”,意味着你能够交付自己当前的任务,而且符合估算的时间范围)如果遇到需要解决的问题,可以在每日立会之后处理。

实现一项目的必要前提:

1.站

2.敏捷项目必须提供能够“安全失败”的环境,团队成员不会因为没有达成任务承诺遭受惩罚。

大家要能够安全说出任务状态的真实情况,并且了解项目环境的现实情况。有时,我们的估算可能很糟糕(只是估算而已,又不是承诺),又或者某些事情的发生让某些成员无法完成任务,整体环境必须让他们能够说出真实情况,这样团队成员就能调整他们的日程表,将任务排序,并调整适应项目的现实。

站会的主要内容:

从PM、RD到QA,每个人发言,内容为:1. 昨天干了什么,2.遇到什么问题,3.今天准备干什么。如果有想要分享给大家的知识,也可以在此分享。

最后主持人总结一下,然后根据实际遇到的问题,少数人进行线下沟通、跟进、解决。

站会的时间尽量控制在十分钟左右。

开站会的一些技巧

(1)轮流主持

轮流主持能提高团队成员的参与度,且如果主持人临时有事,也不会因此无法开展,通常每次站会结束时指定下次站会的主持人。

(2)解决问题不放在会议中

会议中仅抛出问题,解决问题放在站会结束后,相关人参与。目的是避免浪费大家的时间。

(3)早上举行

可以让所有人按时来,按时工作。

可以让每个人更清楚今天自己该干什么。

晚上每个人进度不一,作息时间不一样,早上说昨天干了什么更准确。

(4)卡片墙

有了迭代的总体计划,还需要细化到对每个story进行管理,除了之前的估点外,我们使用卡片墙对其进行管理。

卡片墙如下图所示:


需求池:所有新建的story(一般为未经过估点的)卡片贴在此处。

待开发:所有待开发的story卡片贴在此处。

需求池->待开发:讲解沟通完需求、估完点、补充完验收标准后,移动。

开发中:所有正在开发的story卡片贴在此处

待开发->开发中:RD将story拆分完task,并给QA讲解task实现思路,QA同意后,移动。

待测试:所有开发完成,等待QA测试的story卡片贴在此处。

开发中->待测试:RD开发完成story,且完成单测、集成测试编写,和经过仔细的自测后,移动。

测试中:所有QA正在测试的story卡片贴在此处。

QA singn off:所有经过QA测试,QA认为可以上线的story卡片贴在此处。

测试中->QA singn off:QA经过仔细测试,bug都被修复验证,认为story符合上线标准时,移动。

已验证:所有经过PM验收,可上线的story卡片贴在此处。

QA singn off->已验证:PM在验收环境中验收,认为符合需求后,移动。

加速区:所有需要加速解决的story卡片贴在此处。如卡片中有block测试的bug急需修复,等。

block区:所有被一些问题block的story卡片放在此处。

卡片:story卡、task卡(story编号、估点数、用户故事)。

角色卡FE、RD、QA的名字,以不同颜色区分,分别写上人名,用于贴在story上。谁在做什么,谁忙谁闲,有多少剩余人力,一目了然。

上线时间:略。

(5)燃烧图

使用燃烧图,计划及其变化,以及每天进度一目了然。

燃烧图如下

1、X轴为时间,一般是迭代周期的每一天;

2、Y轴为工作量,根据项目情况,可以用已完成估点或已完成story点数来表示;

3、最开始,计算出本次迭代要完成的所有工作量(作为y轴刻度,迭代天数作为x轴刻度),然后,每天站立会议时,了解前一天已经完成的工作量,并计算出迄今为止完成的工作总量。把其画在Y轴上,以此类推(并把y点连接成线)。如果计划比较(理想)准确,燃烧图的最后一天”燃烧“折线将和总工作量折线相交;

(6)总结

以上五项,简单易实现,用很低的时间成本就能做出“计划”,并保证计划的落实,且能快速适应变化!


4.没有详细设计如何保证设计没有问题?

challenge:如何让设计上的问题在开发前暴露出来,并解决?

在敏捷开发中,我们认为沟通交流胜过面面俱到的文档,相对于编写详细设计文档,RD更愿意给相关人员讲解他的设计,甚至给QA讲解代码,因此对详细设计不做要求。

那么,没有详设,如何让设计上的问题在开发前暴露出来,并解决?

我的解决方案如下:

增加详设交流环节,且由RD推动

1)在开发之前,增加详设交流环节,RD进行task拆分和详设讲解。

2)由RD推动此环节,在开发之前主动给相关QA和关注的leader讲解, QA提出需要了解一些复杂逻辑的实现方法,RD进行讲解。讲解后,卡片才能从待开发移到开发中。

3)story较复杂时,RD会提供简略的详设,一方面理清RD思路,一方面便于QA理解达成一致。

此外,在QA测试之前,如有需要,RD还会给QA讲解详细的实现方式,弥补没有文档的不足。


5.没有测试设计如何保证测试质量?

challenge:没有之前那么严密的测试设计,如何保证无漏测?

虽然没有之前那么标准的测试设计,但我们摸索出了自己的规避风险的方法:

每个story,都有一个固定的测试设计环节,以自己喜好的方式,如:画简图、脑图、列list等,仔细考虑等价类、边界条件、异常分支等,作为实际测试的思路,以便真正理清自己思路,规避测试模式变更带来的风险。

在每个story中,都会有验收标准,验收标准和PM一块编写,由RD review,也作为RD自测和编写自动化测试的依据与要求,一方面提高代码质量,一方面保证测试质量。

PS:

1.如果有测试经验较少的新人加入,可以在初期让新人和之前一样编写测试设计,作为story的附件。待训练成熟后,再过渡到敏捷的模式,以规避新人经验不足导致的漏测风险。

2.如果团队中测试人员较多时,建议编写简单的测试设计,以便整个项目的质量可控。


6.何时提测?提测频繁,如何降低提测成本?提测时间不固定,如何分工?

challenge:没有固定提测时间?没有正式提测?随时提测?

(1)随时提测

没有固定的提测时间,RD完成一个story ,满足上述提测条件,便通知QA提测(无论以什么方式通知),QA即可部署最新版本进行测试。

(2)自动化部署

随时提测,就意味着需要更频繁的部署,此时,不能再依赖手工部署,必须实现部署自动化。

通过在hudson上调用编写的自动化部署脚本,已可一键自动化部署,收益不错,其他项目也有效仿。

(3)测试分工

因为随时提测,stroy的完成时间不确定,如果事先分好了谁测什么,很可能造成QA某时候空着,有时候工作堆积,这样时间利用率低。

因此,我们需要每个QA熟悉所有模块迭代开始时不分工,在迭代中临时分工。这无疑也是对QA的一个很大的挑战。


7.如何提高RD代码质量?

challenge:提高代码质量、降低RD和QA的人力比!

提高RD代码质量对QA来说是一个亘古不变的问题,路漫漫而修远兮。。。

目前我们的解决方案就是:要求并监督RD做单测和集成测试。最终目标为测试驱动开发(TDD)。

在敏捷团队中,QA的负担已经很重了,此时应该果断把之前从RD那边分担过来的集成测试自动化(IT)再还回去,并且推动RD把单测(UT)落地,从而提高RD的代码质量,降低bug率,减少回归时间,最终降低RD、QA人力比,成为真正的敏捷QA。

A. UT

完全由RD编写,目前QA正在对RDs进行一对一的单测培训,将对RD整体的单测水平有很大提升,目前已有RD为提高代码可测性进行了代码重构。培训完成之后,将对RD单测覆盖率会有一定要求。后续所有单测将会被加入到quick build中。

B. IT

新增代码的IT将全部由RD编写,QA对其进行review,有时间的话会帮助RD设计一些case,由RD来实现。

IT被作为story达到提测质量的一个必要条件,RD必须对story中新增功能的验收条件达到全覆盖。

C. ST

ST由QA负责,目标是覆盖所有的主干流程,既可弥补自动化覆盖不到前端代码的不足,又能减少QA回归工作量。


8.没有准入,怎么保证提测质量?

challenge:没有准入,RD提测质量太差怎么办?

以前的瀑布流程,为保证提测质量,QA会做一个准入冒烟,通常一个模块几个case,如果case pass率小于85%,则会打回。QA在准入测试也会花费比较大的时间成本。

如今story粒度相对较小,提测太频繁,做准入是不太现实了,但提测质量还是得保证,经过不断地摸索,我们的应对措施为,限定卡片从开发中移动到待测试必须满足的前提条件,具体如下:

  1. QA将提测story的验收条件分为两部分(a.新增功能、b.原有相关功能)
  2. RD提测之前,需保证所有验收条件100%通过,否则视为提测质量不合格,产生的bug在迭代回顾会议中进行总结学习。
  3. RD提测之前,需保证验收条件中所有新增功能的service层代码,都被自动化集成测试case覆盖,若有特殊情况,提测时需做特殊说明。若QA review时不满足新增功能全覆盖,将在迭代回顾会议上进行case study,后续还得使用工具保证。
  4. RD提测前,需完成必要的单测(还待完善)
  5. RD提测前,需要进行复杂逻辑的CR,CR规则还在试行中。

使用以上的5条,不仅保证了提测质量,且QA几乎不再需要为准入投入时间,同时,集成测试被落地后,后续的回归工作也会慢慢减少。

经过两个迭代的试行,bug量显著降低了,取得了不错的效果。


9.如何避免新增story影响已有功能造成质量问题?

challenge:没有全面回归,如何保证质量?

基于Story的敏捷,要求每个story测试完成都可直接上线,也就是说story从测试中移动到QA sign off后,质量达到上线标准,且须保证不破坏已有功能。

如果QA在sign off每个story之前,都对前面的story和已有的功能做全面回归的话,估计很快就会被累死。

怎么解决此问题呢?

临时解决方案:

(1)code frees环节

RD在主干上开发(减小大量merge产生的风险),在上线之前,会有一个code frees环节,从主干上拉出一个release branch(简称RB),用于本迭代的上线。

根据敏捷的经验,在所有story都移到QA sign off区后,再拉RB,因为RB拉得太早,QA的工作量会double,敏捷周期本不太长,测试和开发在stroy间也是并行的,因此 开发完所有story的时间点和QA测试完所有stroy之间的时间不会很长,因此原则上在所有story都移到QA sign off区后,再拉RB,如果情况特殊,也要等QA大致过一遍stroy后,QA点头后再拉RB。否则RB上提交次数太多,工作量和风险都相对较大,拉RB的意义就不明显了。

(2)迭代回归

RD继续在主干上开发下一迭代的story,QA在此RB中回归本迭代的内容及可能影响到的原有功能,并测试上线步骤。

用迭代回归,而不是每个story完成之后都回归,减少回归工作量,作为临时方案。

长远目标:

推动RD完成UT、IT,QA完成ST,使自动化测试覆盖已有功能,最终将QA从回归中解放出来。


10.上线频繁,如何降低上线的成本?

challenge:每次上线都会花时间去测上线步骤,上线频繁,如何降低成本?

答案当然是自动化上线。

将web和server这种每次上线除配置文件修改,其余操作都一样的上线做成自动化上线。

将文件替换这样的上线步骤做成脚本,QA测试脚本,上线执行脚本即可。


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

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

敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 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导致,由于影响时间过长给公司造成的损失巨大,还被质疑为什么这么明显简单的问题上线之后没人发现。
2017-02-20 17:25:36 iteye_6192 阅读数 173

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

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

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

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

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

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

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

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

  持续提供并获取反馈

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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