分类目录归档:敏捷

说好的团队为质量负责呢?

问:谁应该为质量负责?
答:QA是负责测试把关,主要负责吧,DEV也要在设计和代码上对质量负责。
问:那其他角色呢?
答:BA还好吧,跟质量的关系没那么大。
……

在蓝鲸项目,似乎大家对质量的关注意识有些欠缺,于是在项目上的不同角色、不同工作年限的人之间采样做了一次访谈,上面这个问题就是其中访谈的问题之一。有同事曾提醒我说这种题就是送分题,肯定不会有人回答不出。可是,事实并非如此 …

为什么会这样呢?我猜想可能是大家对质量的理解不一致的缘故,在没有搞清楚什么是质量的前提下,当然也没有可能理解到底谁该为质量负责。

因此,我们来看看质量到底是什么?

质量是什么

产品质量不是检测出来的,从产品生产出来后质量就已经在那了。

——著名的质量管理专家戴明

在讲什么是质量之前,我们有必要区分两个不同的概念:测试只能检测、发现缺陷,而质量要通过缺陷预防来实现。 测试与质量不可同日而语,以后再也不要说“上线这么多问题,测试是怎么测的”这种话了。

那么,质量到底是什么?对于不同的角色、不同的利益相关者,质量有着不同的含义。总的来说,可以分为外部质量和内部质量两种。

1. 外部质量

顾名思义,外部质量就是软件呈现给用户的外部形态,是否有缺陷、是否稳定、是否有性能问题等。也就是最终用户在软件使用过程中的各种体验,包括软件可学习、高效、不易出错、有用、难忘等特性,都属于外部质量范畴。外部质量也可以称为使用质量,主要是从使用软件的用户角度来看的。

外部质量能够被用户直接感知到,直接影响用户的使用,因而显得特别重要,客户/用户一般也比较容易为外部质量买单。

2. 内部质量

同样的,内部质量就是指软件系统内部的质量状态,包括代码的效率、结构、可读性、可扩展性、可靠性和可维护性等。内部质量主要从开发人员角度来看,也称为代码质量。

内部质量不会被最终用户感知到,不容易被客户/用户买单,也常容易被团队忽略。但是,内部质量会影响外部质量,需要团队引起重视,加强设计、开发等环节的质量把控。

3. 内建质量

质量不能被检测出来,要提高软件产品的内、外部质量,都需要通过质量内建(或质量内嵌)的方式,做好每个环节的质量保障工作。质量内建包含自动化测试和手动测试:

  • 自动化测试:从多个层次(单元、组件、端到端等)写自动化测试,并将其作为部署流水线的一部分来执行,每次提交应用程序代码、配置或环境以及运行时所需要软件发生变化时,都要执行这些测试。同时,随着项目业务和技术架构的演进,自动化测试策略也需要随之调整、不断改进。
  • 手动测试:手动测试也是很关键的部分,如需求验证、演示、可用性测试和探索式测试等,在整个项目过程中都应该持之以恒的做下去。

另外,质量内建不仅要考虑功能测试,对于跨功能测试同样是需要做到内建的,比如安全内建、持续性能测试等。

软件构建过程中多大程度上做到了质量内建,有多少缺陷做到了提前预防,这是“内建质量”。内建质量虽然跟内、外部质量不在一个维度,但也是体现质量好坏的一个方面,在此也把它作为衡量质量的一个维度,测试或使用过程中发现的缺陷数量可以作为度量指标。

因此,我们可以从这三个维度来度量软件产品的质量,可以通过以下方式来度量:

外部质量:用户反馈、Support的问题数量

内部质量:code review、结对编程、静态代码质量检查

内建质量:测试环境、生产环境缺陷,Support的反馈

了解了三个维度质量的含义,我们不难理解:

❌质量不是零缺陷,不是百分百的测试覆盖率,也不是没有技术债;
✅质量是快速反馈,任何改变能够快速验证,并且快速修复;
✅质量是把精力都集中在正确的事情上;
✅质量是团队在代码、设计和交付上有信心做出改变;
✅质量是团队对任何改变负责。

容易忽视的质量

从前面对质量的定义,广义的质量其实包括软件产品交付流程中的方方面面,每个环节的一点疏忽都可能对软件质量造成不同程度的影响。下面列举一些从项目上经历的对质量关注有所欠缺的内容:

  • 需求分析过程仓促,或者参与人员角色比较单一,导致业务上下文了解不够,关键场景缺乏考虑等;
  • 忙于交付更多的feature,忽略了对代码质量的关注,该重构的没有重构,在原本不太健康的代码基础上继续增加更多的代码,导致混乱,筑起高高的技术债;
  • 没有足够的测试覆盖,导致新增代码容易破坏已有功能;
  • Dev提交代码后,就投入新代码的开发,对所提交代码缺乏关注,CI pipeline红了不能及时修复,可能影响后面QA的测试进度;
  • 大面积的重构发生在release前夕,无法全面回归,带来很大的风险;
  • 项目初期只考虑少量用户的场景,随着业务的发展,系统功能难以扩展,导致严重性能瓶颈;
  • 技术选型失误,开发困难,没有及时改进,一错再错,最后问题严重到无法弥补;
  • 第三方组件评估不够充分,导致线上环境无法承载等;
  • 开发缺少对异常情况的处理,测试过程缺乏探索,只覆盖到主干路径,边角case可能引发问题;
  • 开发或者测试都只考虑当前功能模块,缺乏更广范围的考虑;
  • 缺乏跨功能需求的关注,导致严重的安全或者性能问题;
  • 对线上环境了解不够,而且没有足够日志信息记录,线上问题难以定位,导致宕机时间过长;
  • ……

这样的问题还有很多很多,无法一一枚举。每个角色,每个环节都有可能出现纰漏,导致产品质量问题。

那么,谁该为质量负责是不是已经很清楚了?

谁该为质量负责

前面已经讲到,质量是贯穿项目整个生命周期的非常关键的部分,质量保障工作也是需要在每个环节加强关注,每个角色都需要为质量负责。

上表列出的是敏捷开发流程中的各个实践活动,它们都与质量有关,每个活动都要求多个不同的角色同时参与。

下面从敏捷团队三个主力角色BA、QA和Dev的不同视角来看看各自怎么为质量负责。

BA:Busines Analyst,业务分析师

BA主要负责业务需求的分析工作,要理解客户的业务,并将业务分解成便于Dev和QA理解的功能点,同时,还要能够帮助用户验证开发完成的软件系统功能,并展示给客户。需求作为软件开发的源头,是极为关键的。

BA视角的质量,主要是需求分析的准确性和清晰度,要帮助团队对需求有一致的认识,从用户旅程的角度关注交付给最终用户的产品是否真的带来了价值。

Dev:Developer,开发人员

Dev作为软件系统实现的主力,对质量内建是至关重要的。从需求的理解、整洁的代码实现、测试覆盖率的保证、频繁的代码提交、持续的集成、对生产环境的关注、运维的支持等方面,都有着不可替代的职责,每个环节都不可忽略。

因此,Dev视角的质量不仅是按照需求实现功能的开发,还要把功能高效的交付给最终用户。

QA:Quality Analyst,质量分析师

QA作为软件质量的倡导者,是唯一一个全流程都要参与的角色,从需求到上线后的支持,每个环节都不可缺。清晰理解需求、制定质量保障策略、做好各个环节的测试工作(手动、自动化、探索式、跨功能、非功能测试,以及生产环境的QA等)、关注项目整体质量状态、及时反馈质量信息给团队、识别业务风险和优先级、帮助优化业务价值,这些都是QA的职责。

三个主力角色中的BA一般都会有从用户旅程的角度去考虑,其实Dev和QA也需要同样的思维模式,不能把story或者AC割裂来看,而是要从整体的用户旅程的角度、端到端的去考虑需求的实现和测试工作。

除了三个主力角色,团队还有其他角色也都是要对质量负责的,比如:架构师要负责项目架构的健康,基础设施负责人要管理和维护好基础设施以保障开发和运维工作的顺利开展,PM要管理好团队的交付节奏、团队成员的工作状态、客户的满意度等,这些都是跟质量相关的。

写在最后

质量不仅是某个角色的事情,团队每个成员都撇不开质量这个话题。团队为质量负责要求所有质量角色都将质量推向看板的左侧,从每个用户故事的开始就将质量融入其中。

软件开发生命周期的每个环节、每个实践活动都不可轻视,只有在每个点上都做好质量的工作,才能实现真正的高质量交付,每个角色对此都有着非常重要的职责。

缺陷分析如何帮助质量内建

质量内建的关键是缺陷预防

近几年,软件开发过程中的质量内建正在逐渐被大家所重视。越早发现的软件缺陷,修复成本越低。质量内建要求在软件开发生命周期的每个阶段做好质量保障工作,预防缺陷的产生。

缺陷预防

说到缺陷预防,通常能够想到的就是测试前移(QA从需求阶段开始介入、TDD/ATDD等)、Code Review等实践,正向的来预防缺陷的产生。

但是,软件系统的生态环境越来越复杂,不确定性增加,缺陷预防的难度也在增加。如果缺陷已经产生,是否还能被利用来帮助质量内建呢?

在《软件缺陷的有效管理》一文中介绍了基本的缺陷分析方法,接下来我们一起探讨一下如何利用缺陷分析来帮助质量内建。

缺陷分析与质量内建

缺陷分析最为关键的是根因分析,找到根因,能够减少缺陷重复出现的可能性,在后续阶段做到缺陷预防,帮助质量内建。

分析根因

引起缺陷的原因主要有下面这几个方面:

  • 需求缺失或者需求不清晰
  • 设计问题
  • 编码错误
  • 测试不够
  • 环境相关(硬件、软件、配置等)

利用5 Why分析法[1]根据缺陷的表象,多问几个为什么,找出根因。下面是一个真实生产环境缺陷的根因分析过程:

上图的根因还可以继续细分,比如为什么这么设计,可能还会有更深层次的问题;同样的,进度紧张导致的需求没有实现,也可能还有更详细的内情可以分析的。最好能一直分析,直到找出真正的根本原因。

定位阶段

找出根本原因之后,同样利用5 Why分析法,基于软件开发生命周期由外往内的问为什么,从而定位引发问题的薄弱环节,找出是哪个环节做的不好导致的问题。拿生产环境的缺陷为例,下面是可能(不限于)的问题列表:

1. 为什么在预生产环境没有发现这个问题?
2. 为什么测试环境没有测出这个问题?
3. 为什么Desk Check没有发现这个问题?
4. 为什么Code review没有发现这个问题?
5. 为什么单元测试没有覆盖到这个问题?
6. 为什么在需求评审的时候没有发现这个问题?
7. ……

定义改进action

找出了根因,并且定位了引发缺陷的最可能阶段,接下来就是通过“What”问题来确定对应的action,预防类似缺陷再次发生,从而帮助质量内建。

不同的根因对应的可能actions有:

总结

质量内建的关键是缺陷预防。

除了正向的考虑加强每个环节的质量保障工作可以预防缺陷,通过分析缺陷的根因、定位问题出现的薄弱环节、制定可行的对应改进措施,可以帮助我们更有的放矢的做好缺陷预防工作,更有效的做好质量内建。


注1:5 Why分析法
所谓5 Why分析法,又称“5问法”,也就是对一个问题点连续以5个“为什么”来提问,以找出其根本原因。根据实际情况,问题的数量不一定要限制在五个,可多可少,适当调整。

再谈敏捷QA

曾经在《敏捷中的QA》一文里介绍了敏捷开发模式下,QA如何参与从需求到测试的每个阶段,在每个实践中如何跟不同角色的合作,以及敏捷QA跟传统开发模式下的测试人员的区别等。

这些内容在今天依然适用,但在真实项目中往往情况比较复杂,总会听到一些困惑或者是质疑的声音。

在敏捷项目团队摸爬滚打多年以后,我想跟大家一起再来聊聊这个话题,下面逐个来分析我所见(听)到的质疑或困惑。

敏捷QA流程必须严格遵守

“如果QA没有参加Kick-off,我们拒绝做Desk Check;如果没有QA参与Desk Check,我们拒绝测试。”

从需求分析到生产环境,推荐QA参与每一个环节,跟多个角色进行充分的沟通和合作。

有人把这个当做圣旨,觉得不管怎样都不能漏掉某个环节,但难免有特殊情况。比如,由于QA请假或者开会等,错过了某一次Desk Check,一定要求等有时间了(甚至第二天或第三天)再补上,没准那个时候代码都已经上到测试环境,完全可以直接测试没必要在折腾大家来做一次全面的Desk Check了。

QA参与每个环节的目的是尽可能早期发现需求或者设计中的不足,做到Bug的预防。如果已经错过了这个“早”,那就没有必要再纠结非要严格进行每个环节了,不然不仅没有意义,还带来浪费。

QA不用了解太多的业务上下文,一样做的很好

“需求来的晚,QA手头忙着测试当前迭代的Story,根本没有时间去参与需求分析,不过这样也不影响,测好当前的卡就可以很好的保障质量了。”

这个想法是狭隘的。敏捷测试的原则之一是优化业务价值。如果连业务上下文都不清楚,如何做到优化业务价值?了解业务上下文的重要性不言而喻。

业务上下文

那么,真的忙的没有时间如何来破解呢?这其实是进入了一个恶性循环,需要找到突破点,打破这个不良环路,让其变成一个良性循环就好了。

不破不立,对于这个循环,就是需要减少测试Story的时间。可行的方案是:加强Desk Check,确保单元测试的覆盖,保证开发验收完成到最终交付的代码在自动化测试的保护下不被后续环节破坏;同时QA参与技术方案的设计讨论,这样测试的时候就可以有针对性的测,必要时候辅助以Bug Bash,由此节省出时间。经过两三个迭代的调整,情况定会有所改善。

技术方案讨论跟QA没什么关系

“技术方案,那是Dev们的事情,QA的重要任务是如何做好测试,参与技术讨论浪费时间。”

知己知彼,百战不殆。如果完全不了解技术实现,很难做到有的放矢。正如前面提到的,QA参与技术方案的讨论,了解更多技术细节,知道技术方案可能的风险,就能更好的指导测试,使测试更有针对性、更高效。

比如,对于微服务架构,了解了服务的熔断和降级机制,测试就能有效覆盖到相关方面。

单元测试Review没有价值

“单元测试还挺复杂,Dev新人写起来都不容易,QA更看不懂。QA Review单元测试,提不出有价值的反馈,感觉是在浪费时间。”

敏捷QA有个实践就是在做Desk Check的时候Review开发人员写的单元测试,其目的是两个方面:

  • 帮助发现漏掉的或者需要修改的测试,QA更好的了解测试覆盖情况
  • 帮助开发人员增加测试Sense,同时也能帮助QA提高代码阅读和理解能力

我理解对于单元测试Review的质疑是由于DEV和QA的相关技能还有所欠缺的情况下可能会发生的情况,但并不能因此否认这个实践的价值。

这时正确的做法是DEV跟QA解释每个测试所测到的内容,而QA从业务的角度考虑有哪些Case是遗漏掉了的。经过一段时间的磨合,我相信Dev的测试Sense和QA阅读代码、理解测试的能力都会得到提高。

必须严格Review每一个单元测试

“我对Dev写的单元测试总是不放心,不严格的Review根本不行。”

另一个极端情况就是,不管花多少时间,认为必须严格Review每个测试,认真的去检查测试的每个实现细节。

对于复杂一点的Story,严格Review每个单元测试,我见过最长的是花了两个小时,到最后大家都已经筋疲力尽…这显然是一种浪费!

QA Review单元测试更多的是关注测试的覆盖情况,而不是关注每个测试的实现细节,后者更多的是属于Code Review范畴。更重要的是,任何实践都不能只关注形式,要看其价值,具体问题具体分析。对于新的团队新的人,可能刚开始需要多花时间去了解所写的测试。而对于成熟的团队,或者是非常有经验的Dev,这个Review过程可以简化,只看测试的标题,或者只是听Dev说一下测试覆盖到了哪些内容就可以了。

我一般要求整个Desk Check控制在15分钟以内,对于特别复杂的Story,最多也不要超过30分钟。

没有发现Bug的测试不是好测试

“这些自动化测试从来没有发现过Bug,ROI太低,没有存在的必要!”

图片来自:https://www.netsolutions.com/insights/wp-content/uploads/2016/08/Why-You-Need-Automation-Testing-For-Mobile-Apps-Th.jpg

由于有些测试执行起来太耗时、测试实现成本和维护成本都很高,大家在讨论要不要去掉这些测试的时候,总能听到上面那样的声音。

其实,自动化的回归测试并不是用来发现Bug的,有数字表明自动化回归测试发现Bug的比例仅有15%。自动化测试只是形成一道保护的屏障,增加对系统质量的信心。

敏捷团队的QA对质量应该有全面的认识,在制定测试策略的时候需要综合考虑多方面因素,要真正理解每个实践、每个活动背后的真实价值。

敏捷QA该怎么做?

关于QA的定义,有下面三个层次:

  1. QA = Quality Assurance质量保障
    第一个层次QA的要求是做好质量保障工作,确保我们交付给客户的软件产品是正常工作的。
  2. QA = Quality Analyst质量分析
    第二个层次的QA通过测试、数据收集的方式,分析系统的质量,识别风险,并反馈给团队,和团队所有成员一起确保交付的质量是合格的。
  3. QA = Quality Advocate质量倡导者
    第三个层次的QA不再局限于只关注质量,通过培养对产品和流程持续改进的思维模式、了解产品的整体质量视图和持续关注产品质量的意识,引导整个团队构建正确的产品,并且正确地构建产品。

敏捷QA需要做到第三个层次,通过分析软件风险并制定相应实践,确保软件在其整个生命周期中持续工作并创造价值,为业务和团队提供信心,从而为客户提供价值。

敏捷QA的所有实践和活动都需要以价值为核心来驱动,根据不同团队的具体情况可以适当调整,且在不同项目阶段应该也是演进式的。敏捷QA跟各个角色的沟通和协作,也是随着团队成员的了解程度、配合默契度不同而有变化,并不是要求一成不变的。

聚焦测试,驱动卓越

在经历了“七年之痒”后,蓝鲸项目进入第八个年头,项目的一切趋于稳定。团队倡导持续改进,可大家的感觉是已经尽力做到最好,这个时候似乎没有什么可以改进的了。为了突破这个局面,项目重新聚焦测试,从质量和测试的角度对现状进行了一次评估。

评估采用的是基于软件测试原则的模型,本文就是跟大家分享一下这个模型。

测试原则

Testing principles

2012年澳大利亚敏捷大会(Agile Australia)上ThoughtWorks的非常资深的测试实践带头人Kristan Vingrys分享了如上测试原则,这些原则是ThoughtWorks的同事们在多年软件测试经验基础上总结出来的。

1. 质量内建(Build quality in)

You cannot inspect quality into the product; it is already there.
— W.Edwards Deming

著名的质量管理专家戴明指出:产品质量不是检测出来的,从产品生产出来后质量就已经在那了。这同样适用于软件产品。

缺陷发现的越晚,修复的成本就越高。质量内建要求我们做好软件开发每个环节,尽早预防缺陷产生,以降低缺陷出现后的修复成本,要减少对创可贴式的补丁(hotfix)的依赖。

Cost of change

推荐实践: TDD、ATDD等

2. 快速反馈(Fast feedback)

每个环节的任何变化都能最快的反馈给需要的人,从而可以基于当下最新信息做出明智的决定,降低风险。这要求我们对系统进行频繁的测试,缩短回归测试的周期。

推荐实践:

  • 符合测试金字塔结构的自动化测试,让每一层的测试都能发挥尽可能大的价值,给出最快速的反馈;
  • 持续集成,尽早排查集成引起的问题,降低集成所带来的风险。
3. 全员参与(Involve everyone)

— 这次上线好多bug,QA是怎么测的?!
— 那个xxx组在上线前发现了很多的bug,他们的QA真给力!

成也QA,败也QA…如果还是这样的认识,那是极为片面的。测试不仅仅是QA的事情,团队成员要一起为质量负责,软件开发生命周期的测试相关活动需要全员的参与。

全员参与的好处是利用不同角色的不同领域知识和不同的思维模式,不仅可以使得测试的质量更高,同时还能最优化利用测试资源,做到价值最大化。

推荐实践:

  • 自动化测试:QA和BA结对用DSL编写测试用例,QA和Dev结对编码实现测试,生成业务人员可读的测试报告;
  • Bug bash(bug大扫除):团队不同角色一起参与的一个找bug的测试活动
4. 测试作为资产(Tests as asset)

自动化测试帮助我们验证系统功能的正确性,好的自动化测试还有文档的功能,是宝贵的资产。如果每个项目都构建自己独立的自动化测试,没有跨项目共享,其浪费显而易见。

这个原则要求把自动化测试的代码跟产品开发的代码一起,当做资产管理起来,在不同项目间做到尽可能的复用。这笔宝贵的资产能帮助我们更好的统计跨项目的测试覆盖率,更好的优化测试。

推荐实践:利用版本控制管理工具把测试代码和产品构建代码一起管理,都作为产品的一部分。

5. 更快的交付(Faster delivery into production)

任何一个idea越快做成软件产品交付给用户,给企业带来的价值越大。

该原则要求我们把测试活动融入软件开发生命周期的每个环节,不要在后期进行长时间的集中测试;同时测试人员的关注点不再是发现更多的bug以阻止不符合质量要求的产品上线,而是把目标放在如何能够帮助团队尽快的让产品上线,让企业投资回报更早,也就是更快的赚钱。

推荐实践:自动化构建流水线、关注平均恢复时间、发布与部署解耦等。

Pipeline
6. 清晰一致的测试视图(Clear and consistent view of testing)

可视化的报告给客户和内部团队展示测试的状态和产品内外部的质量,对项目的质量和风险把控是非常有帮助的。不同项目各自采用五花八门的图表样式,将不利于项目间的信息共享和比较,无端增加复杂性,带来浪费。

因此,我们需要把状态报告做的尽可能简单、清晰,并且保持跨项目的指标一致性;同时,我们不应该为了让某个指标变得好看而改变我们的行为,整个报告要诚实开放,这样才能真实反映出项目的状况。

7. 优化业务价值(Optimize business value)

开发软件无疑是要给客户的业务带来价值,软件测试也需要为这个目标服务,测试要跟业务价值保持一致,帮助客户优化业务价值。要求做到:

  • 测试不仅是保险,不仅是保证软件质量的;
  • 要有目的的关注变化的特性,不要盲目的散弹枪式的对任何特性进行测试,要有优先级;
  • 要能帮助企业驱动新的特性和功能;
  • 帮助客户创造安全的尝试新点子的环境,提供快速的反馈。

推荐实践:

  • 基于风险的测试,根据业务优先级需要调整测试策略,在测试过程中尽可能规避给业务带来的风险;
  • 生产环境下的QA,通过收集生产环境的真实用户行为和应用使用数据,对业务的优化做出贡献。

评估模型以及在项目中的应用

评估模型就是将上述七条原则的每一条细化,列出该原则对应的实践和行为,并给每个实践或行为设定0-5分的不同评分标准,最后统计各个原则的总分,形成类似下图的结果报告:

Result Model

在项目中的应用

以Cristan分享的模型为基础,由Tech Lead和几个DEV、QA成立一个评估小组。

第一步:分别根据各自的理解给项目打分,结果是很有意思的,请看下图:

结果对比图

根据这些结果,可以看出大家的认识是不太一致的。

第二步:评估小组对模型中的每条细节进行review,做适当修改以更符合项目情况,并且在评估小组内大家达成共识。其中,所做的修改包括修改原有的实践评分指标、增加新的更适合项目和当前技术趋势的实践、删除过时的或者不符合项目特点的实践。

第三步:根据更新过后的模型指标对项目上的一个Team做评估试点,详细分析该team对应到测试原则各个维度的well和less well部分,由评估小组成员一起打分,得到该team的评估结果图。

第四步:根据评估结果并结合项目目标排定需要改进的优先级,制定出改进action,并更新给试点team执行。

后续:试点一个周期后再次评估,并重新review评估模型,再推行到整个项目。同时,周期性的进行新的评估和制定新的action,以做到持续的改进和优化。

总结

图片来自网络

应用程序的质量、测试的快速性、以及上线后轻松自信的更新服务的能力,是帮助企业业务价值最大化的关键因素之一,一直是我们所追求的。

基于测试原则的评估模型,可以帮助我们在追求这个目标的道路上少走弯路,帮助我们持续的改进,以驱动出更加卓越的软件。

为什么不能每周发布一次?

图片发自简书App

“看,车来了!不过这趟车貌似咱赶不上了吧?!”
“啊!那快点跑,错过这趟就得再等半个小时!”
……

好无奈,可是真的赶不上也没有办法,这个场景很多人都经历过。

“这个release又是一定包就开始上hotfix,四天跟了四个,我根本没时间做回归测试!” QA小静同学抱怨道。
“每次都是定包后就开始无休止的上hotfix,咱们还不如改成每周发布一次!”Dev大鹏同学也被hotfix折磨苦了。

这是发生在蓝鲸项目的一次真实而平常的对话,跟前面赶公交车的场景有什么关系呢?

发车间隔与发布周期

发车间隔的不同带给乘客的感受会完全不同。

有些公交车很少,每半个小时一趟,有时候眼看着一辆车来了又走了,没赶上的心情无比懊恼,下一趟还得等上半个小时啊!实在着急的可能考虑叫一辆快车赶紧走…

而有些公交车发车间隔非常短,几分钟一趟,就算错过一趟也无需等待太久,只要不是着急去救火的乘客一般都不会太在乎。

图片发自简书App

项目的不同发布周期带给客户的感受也是类似的。

蓝鲸项目的发布周期跟第一种公交车发车间隔非常类似,是四周发布一次,如果这次没能上线的功能,或者有导致功能不能正常工作的缺陷,下次发布上的话,就得再等一个月。一个月,那是多少白花花的银子啊!对于那些特别重要的功能,客户着急就要求上hotfix,于是就出现了前面小静和大鹏对话中的场景。

Hotfix是否真的能解决软件交付过程中的问题呢?其实不然。

Hotfix的引入带来很多额外的工作,影响新功能的按时交付,会打乱交付节奏,从而有形成恶性循环的趋势。既然这样,大家一定希望能解决,而且通过公交车的例子很容易想到前面大鹏说的那个方案。

如果发布周期缩短,比如说一周甚至更短,这次没上的功能也不用那么着急的通过hotfix来上线,就能解决问题。那么蓝鲸项目为什么不一周发布一次呢?

如何才能缩短发布周期?

发布周期的影响因素

1. 合适的迭代计划和合理的需求切分

半个小时一趟的公交车,就算车子足够大能够承载半个小时到达的乘客数,可是会导致乘客等待时间过长,造成很多不便和耽误。要解决这种情况,可以把大型公交车换成多辆小型车,增加发车次数,缩短发车间隔。发车间隔缩短到多少,车子换成多大的都是需要仔细分析和考虑的问题。

映射到蓝鲸项目,要缩短发布周期,就得有相应的小规模需求正好能够乘坐小发布周期那样的小车,要做好发布计划和需求切分。

这样,对需求源的要求很高,需要客户那头的紧密配合。要想缩短发布周期,首先必须得有足够的、粒度合适的功能需求,能够正好安排到较短的发布周期上线。如果需求范围不能提前确定好,就没法提前做好短周期发布计划,不可能把发布周期缩短。

2. 强大的开发能力

乘客的需求分析清楚了,要想缩短发车间隔非常关键的一点就是要有足够的安全的车和靠谱的司机。 如果这一点满足不了,其他都免谈。

对应到蓝鲸项目,安全的车子和靠谱的司机组成了团队强大的开发能力,包括架构支撑和人员技能。

车子就是对持续交付友好的技术架构,需要减少模块间的依赖,比如采用微服务。蓝鲸项目是一个七年之久的老项目,很多陈年依赖已经形成,要拆分不是一时半会的事情,团队正在朝着这个方向努力。

司机就是我们的开发团队,除了要有必要的开发技能外,要做到靠谱就得透彻理解持续交付的精髓,需要团队人人都有质量意识,人人都有发布周期的紧迫感,并且能够做到高效合作,从需求划分、代码质量、测试保障等做好各个环节的工作,做好缺陷的预防和监控,不让严重缺陷流入后面阶段。

蓝鲸项目由于新人较多、人员流动大等原因,对于质量意识和紧迫感都有待提高。 不过,在各位QA的影响下,团队人员的质量意识、紧迫感都在改善,新人的技能也在不断的学习和实践中得到提高,但仍然不能放松警惕,需要时刻保持向前的精神面貌。

3. 充分必要的测试支撑

有了足够的安全的车和靠谱的司机,还得保证路况足够好,这样才能做到不管到达哪个站,间隔都是相同的。

要想蓝鲸项目的持续交付能够顺利前行,一路畅通,需要严格做好质量内建,各层都有充分必要的自动化测试保护,减少新功能开发过程中对老功能的破坏;同时持续集成流水线也要很健全,不能耽误代码提交和出包,从而影响开发和测试的进度。

蓝鲸项目开发年限已久,复杂度很高,在持续交付的路上行走的有些坎坷。目前团队正在这些方面努力采取改进措施,取得了不少进展,但确实还有不少提高的空间。

前景堪忧?

图片发自简书App

过去七年,蓝鲸的持续交付之路有些坎坷,但不应因此而失去信心。

通过跟公交系统的对比,我们可以看到蓝鲸项目要缩短发布周期、杜绝hotfix,需要从需求切分、迭代规划、技术架构、团队能力和测试策略等多方面进行优化,才能保证持续、快速的发布节奏,这是一个系统的问题。

七年之痒已经平安度过,蓝鲸团队正在采取相应的改进措施,一旦做好了上述各方面的优化,相信下一个七年一周发布一次或者更短发布周期都将不是梦!

大规模团队的QA如何高效合作

“你们团队QA和DEV的人员比例是多少?”
“我们团队一般有1个QA和3~4对DEV pair.”

经常会被问到这样的问题,一般的小团队都是这样的人员比例,QA也不会觉得压力有多大。当多个特性团队工作在同一个代码库、分别在开发同一个系统的不同功能的时候,虽然每个特性团队也保持前面所述的比例,对于QA的挑战却要大得多,那是因为:

  • QA不仅要了解自己特性团队的需求,还需要了解其他团队的需求,因为这些功能都在同一个系统上,联系必然是很紧密的;
  • 某个团队发现的软件缺陷的根源、错误日志信息,在其他团队也可能发生,这些信息需要共享;
  • 某个特性团队有任何基础设施、测试环境配置文件的变化都得让所有团队知晓,而QA是其中沟通这个内容最恰当的角色;
  • ……
图片来自网络
(图片来自网络)

由此可见,大规模团队的QA不像小团队那么简单,沟通的成本要高很多。如果没有及时沟通,将会造成信息不对称,要补救所花费的额外精力是比较大的。当然,大规模团队不仅QA的沟通成本增加,其他角色也一样,只是因为我是QA嘛,就跟大家聊聊我们QA是如何应对这种大规模团队的挑战的。

集体参加story的kickoff和desk check

不管哪个组有kickoff和desk check,各组的QA都一起参加,这样基本能搞清楚各个团队都在开发什么功能。只有两三个特性团队的时候,这个方法还勉强行得通。但随着团队越来越多,在高峰期的时候,QA可能一天都在这两个活动中切换,通过这种方式了解各组的需求似乎不是一种高效的方式……

集体参加各组的feature kickoff

一个release做一个feature的话,QA参加feature kickoff每个release只需要参加一次,貌似还可以的样子。但由于各组的发布周期是一样的,各组做feature kickoff的时候,QA正是忙着上一个发布周期验收测试的收尾阶段,同时也是忙着review自己所在特性团队story的时候,一般都比较忙,尤其特性团队越来越多,如果还要集中参加其他组的feature kickoff,一定会忙不开……

前面这两项我们团队都有实践过,但显然都没能很好的坚持,因为手头的确有些忙不过来,这些自然优先级就变低了。大家始终坚信信息共享的重要性,于是团队在不断摸索中找到以下两种方式。

定期catch up

定一个每周一次的例会,要求QA们合理安排手头工作,务必参加该例会。例会上每个人
给大家介绍自己组内的feature,更新状态,把遇到的困难、blocker、风险等拿出来跟大家一起讨论,讨论对策,并且对一些接下来要做的事情清晰列出来,找到专人own,下次例会的时候检查执行情况。

QA内部showcase

在每个发布周期,在QA们做一次showcase,共享组内新开发功能特性。这样不仅锻炼了QA做好showcase的能力,同时也给其他团队QA共享了业务功能信息。

这两项实践以来,大家感觉到的收益还是蛮大的,除了知识、信息共享之外,也增进了QA间的相互了解,对于大家一起合作带来很大的帮助。

当然,除了这种具体的实践,更重要的是大家都有一颗愿意分享的心。随着例会和内部showcase的开展,QA们共享信息的意识得到了加强,日常工作中遇到某种情况觉得其他团队需要知道的就会主动分享出来。

大团队带来的挑战不是那么轻松容易解决,关于如何能高效协作,我们也还在继续摸索中。

不知道您所在团队是否也面临如此挑战?是否愿意和我们大家一起分享分享呢?

神圣的QA——写给应届毕业生

你有没有过下面的经历:

  • 在谷歌浏览器输入一个网址,出来一个错误提示:“不支持当前浏览器,请用IE访问”…
  • 换成IE,重新打开该网站,输入用户信息注册一个新用户,随后收到一封注册成功邮件,里边直接包含刚刚注册的密码…
  • 用注册的用户名密码登录进去,又不知道所需要的功能入口在哪里…
  • 翻遍了一层又一层的菜单,终于找到了入口,进去打开的是一个列表,足足等了2分钟才加载完成…
  • 从列表中找到自己需要的那个信息,点击“查看详情”,却显示一堆乱码…
这么多问题 :(

一次性碰到上面的各种当然属于极端现象,但我敢说,你一定碰到过其中的问题不止一次,而且碰到了一定很郁闷。这些都是软件缺陷,分别是兼容性、安全性、易用性、性能和功能方面的缺陷,一旦出现将会给企业和用户带来不同严重程度的影响。

这种糟糕的体验有没有使你产生想去优化的冲动?你是否想知道如何帮助软件开发团队开发出缺陷更少的软件产品?如果你的回答是肯定的,那么请跟我一起来做QA吧:)

QA是什么?

狭义的理解就是软件测试,软件测试工程师常被称为QA;广义上,QA就是在软件开发过程中做好软件质量分析和保证的人员。

QA的职责有哪些?

QA的职责

下面结合一个简单的例子说明QA的职责:生产杯子。

1. 理解和澄清业务需求

需求是软件开发的源头,需求的正确性、合理性对软件开发的质量有着至关重要的作用。QA的一个很重要的职责就是澄清需求、验证需求合理性,并且帮助团队一致理解需求。

需求包括功能需求,也包括各种非功能需求:性能、安全、易用性、兼容性等。所谓理解和澄清业务需求,就是需要把业务相关的功能和非功能需求都搞清楚了。

对于生产杯子的例子,QA需要搞清楚杯子的功能有哪些:普通的盛水、加热、保温、带吸管等等。杯子的功能可能还远不止这些,这就需要发散性思维,去挖掘可能得用途并进行确认、测试。除了功能需求以外,还有要考虑的非功能需求可能有:材质耐热性、耐摔性、跟各种液体的兼容性、安全性(是否有毒?是否可以砸伤人?)……

注意

需求的澄清是个过程,并不是在开始开发和测试之前要搞清楚所有的需求(这也是不可能的),同时可以在开发和测试过程中不断去澄清需求、优化业务流程。

2. 制定策略并设计测试

澄清了需求,还得知道怎么去验证软件产品是否满足了需求,这就需要制定测试策略,并根据策略设计测试。大概说来,需要确定测试范围、测试阶段,覆盖要求的测试范围都需要什么类型的测试(功能与非功能等),在每个阶段采用什么测试方法,手动测试和自动化测试的分配比例,如何设计手动和自动化测试的测试用例,用什么工具实现功能、性能和安全测试的自动化等。

对于杯子来说,确定需求之后,针对每一项需求指标需要确认可能采取的不同测试方法,需要考虑如何测试盛水和加热功能、如何测试耐摔性(直接摔吗?)、以及如何测试安全性等等。

可以参考测试四象限测试金字塔等模型来制定测试策略,并根据产品发布周期制定具体的测试计划、设计测试内容。

注意

设计测试,不仅是指设计测试用例。
四象限和金字塔只是个参考,不可以生搬硬套,而且有些内容稍有争议,但参考价值还是很大的。

3. 执行和实现测试

根据制定的测试策略和测试计划、设计好的测试用例,执行手动的验收测试和探索式测试等,实现和执行功能和非功能的自动化测试,统计和生成测试结果报告。

对于生产的杯子,根据设计的测试方案对产品(半成品)进行测试,可能的方式有:往里加水,直接摔到地板上,加热至100摄氏度,往里注入硫酸等。测试之后,统计和生成杯子的测试结果报告,内容包括但不限于测试样品集、测试方法、测试结果、成功率等。

4. 缺陷管理

测试之后,必然会发现很多的缺陷,对这些缺陷进行有效的管理是QA们一个非常重要的职责之一。缺陷管理包括以下内容:

  • 记录缺陷
    发现缺陷以后,QA需要尽自己所能去调查缺陷,收集所有跟缺陷相关的信息,包括不限于出现的环境(操作系统、浏览器和不同的测试环境等)、重现步骤、屏幕截图、日志等,并将这些信息简单清晰的记录下来。
  • 确定严重性和优先级
    严重性是指缺陷发生对用户所产生影响的严重程度,优先级是指需要修复的紧急程度,通常需要结合严重性和发布计划等来确定。新QA往往比较容易混淆这两个概念,注意它们是有区别的,优先级高的严重性不一定高,而严重性高的往往优先级比较高。具体需要根据产品和项目实际情况来确定。
  • 分析和跟踪缺陷
    开发人员修复缺陷之后,QA需要测试和验证缺陷,很多时候缺陷被验证之后就没人管了,但缺陷的生命周期并没有结束,后面还有非常重要的分析和跟踪阶段。在这个阶段,QA要分析缺陷产生的原因,影响的功能模块,过去一段时间以来的发展趋势等,根据这些分析结果制定下一阶段避免和减少同样缺陷产生所需要采取的行动措施,并且跟踪行动执行的详细情况。
注意

缺陷分析是非常重要的一个环节,但却很容易被忽略。关于缺陷管理的更多详细内容请参考我的另一篇文章《软件缺陷的有效管理》

再来看看杯子的例子,执行一番测试之后,可能发现如下缺陷:

  1. 容积为100毫升的量杯只能盛水80毫升
  2. 杯子表面不够光滑但不影响使用
  3. 清水倒进去水变成酸的了

第一个是严重的功能缺陷,第二个属于UI问题,第三个可能是一个非常严重的安全性问题。QA需要将这些缺陷报告,并根据严重性和产品流程等来安排优先级,督促开发人员及时修复高优先级的缺陷。缺陷修复并重新测试没问题之后,要分析统计,找出产生缺陷的环节,并采取措施防止下一批杯子出现同样的问题。

5. 质量反馈和风险意识

软件产品的质量不是QA这一个角色能保证的,而是需要整个开发团队所有人员齐心协力,共同为质量负责。QA作为质量分析保证的主力军,对产品质量需要有更清晰的认识,及时识别质量风险,并反馈给整个团队。

将质量相关因素可视化出来,是反馈给团队的较为有效的方式。质量可视化包括但不限于cycle time、自动化测试覆盖率、缺陷分析报告、错误日志分析、网站分析工具统计报告、性能监控数据、安全扫描结果、用户反馈、产品环境下的缺陷统计等,可以根据项目和产品具体情况具体定义。

定期或者不定期的把这些可视化结果反馈给团队,有助于形成团队对质量的统一认识,发挥团队每个成员对于质量保证的主观能动性,从而一起制定和调整下一阶段的质量保证策略。

测试了一批杯子之后,将杯子的质量相关情况反馈给团队,内容可能是:

  • 最近这批杯子出现的缺陷明显比上一批少,可以鼓励团队再接再厉;
  • 这批杯子出现了很多严重缺陷,那么就需要组织团队一起讨论问题根源,考虑采取措施防止问题重复出现;
  • 某一批杯子等待很久才可测,需要分析原因,采取改进行动;
  • 这一批杯子生产效率明显比以前有提高,同样可以确认效率提高的原因,后续可以以此为参考持续改进和提高。

QA的必备技能要求

硬技能之扎实的计算机基础

软件测试的概念虽然已经出现多年,但QA或者软件测试工程师还是被很多人误认为就是简单的点击应用程序进行测试,是一项没有技术含量的工作。其实,从前面对QA职责的描述,大家可以看到,QA的技能要求还是蛮高的,其中非常关键的一项就是具备扎实的计算机基础,具备基本的编码能力和数据库操作能力。

只有了解系统的工作原理,才能更好的去验证系统的完备性,发现问题才能更快更有效的初步定位。因此,下次有人问你为啥选择软件测试行业,千万别说是因为自己技术不行,那样会被鄙视的。

各项软技能

从QA的职责要求可以看出,做好QA还需要多方面的软技能:

  • 快速理解业务的能力:通常丰富的领域知识和快速学习新事物的能力可以帮助快速理解业务。
  • 分析能力和定位问题的能力:执行测试和定位缺陷的过程中,这种能力非常重要。
  • 良好的沟通表达能力,包括口头和书面沟通:QA需要跟客户、需求人员、开发人员等不同角色沟通以更好的完成工作,良好的沟通将会事半功倍。
  • 踏实、认真、细心:每一个测试、每一个缺陷都需要认真的对待,容不得半点浮躁,这些技能无需细说。

当然,除此之外,能在QA职业道路上有良好的发展,极其重要的一点是对软件质量相关工作有浓厚的兴趣。

写在最后

QA在一个软件开发团队,能与需求人员一起分析需求,能与开发人员一起编写测试,能给团队和客户详细展示系统功能,还能更新整个产品/项目的质量状态,是比PM更为了解产品/项目的人,听起来就很厉害,对不对?

是的,QA就是这么神圣的工作!你心动了吗?

敏捷实践Showcase的七宗罪

Showcase介绍

Showcase

Showcase就是开发团队把开发好的功能给客户的Product Owner(以下简称PO)等业务相关人员演示,以获取他们对所开发系统的反馈,是敏捷开发流程中的一个实践,一般频率是一个迭代一次,也可以根据项目具体情况做调整。Showcase是做功能演示,同时也是展示开发团队面貌的时刻,其重要性不言而喻,但据我经历的项目,总能看到一些不是很理想的地方。

Showcase之七宗罪

Showcase七宗罪

1. 准备工作没做好

所有人就位,准备开始showcase的时候,突然发现环境没有ready,连不上了!

好不容易把环境弄好了,开始showcase,可是数据又没有ready,还要临时创建,花了大半天时间(创建、准备数据)才终于show到了真正要演示的功能……

主讲人手忙脚乱,而其他人都要在这种忙乱中等待,浪费了很多宝贵的时间,尤其是对于PO那些重要人物来说。

###### 正确做法:充分做好准备工作

确定要做showcase的功能后,需要提前把以下事情提前做好:

  • 从业务的角度把整个要演示的功能尽可能的串起来,准备好showcase演示的步骤;
  • 演示数据也需要准备好,showcase的时候可以直接使用,只需要操作所演示功能部分,不需要临场创建准备数据;
  • 演示环境要提前准备好,包括部署好需要演示的应用程序版本,而且要告诉团队不要破坏了准备好的环境。

2. 没有上下文铺垫

着急忙慌的准备好一切之后,就开始页面操作了,也不先介绍一下要演示功能的来龙去脉,不说一下这个功能是干嘛的。这样,那些日理万机的PO等业务人员,他们很有可能没见过这个系统功能的样子,容易被搞得云里雾里、不知所云……

###### 正确做法:开始演示前要先介绍上下文

根据自己对所演示功能的理解,先介绍该功能的业务价值,满足了用户的什么业务需求,让在座的各位业务人员能够更容易理解后续showcase的内容。

3. 逐条过AC

Showcase的过程就是按照用户故事(story)的验收标准(AC, Acceptance Criteria)一条一条的过一遍,没有连贯性,这样的演示过程很难让观众把每条AC跟整体的系统特性、真正的业务场景联系起来,容易迷失,因此,常常会有演示完了一个story,而客户却问这是实现了什么业务需求……

正确做法:以功能为单位演示

不要一个一个用户故事演示,而是将整个功能串起来,最好定义出一个一个的业务场景演示给客户看,并且尽量使用业务语言描述。这样,让客户的业务人员感觉更有亲切感,看到开发团队的人员能够用业务语言描述和演示,他们一定会留下好的印象。

4. 企图覆盖所有路径

系统功能通常会有不同路径实现的是同一个相同或类似的功能,比如一个上传文件的功能有多个入口,但到达的上传文件页面是相似的。有人在演示这个文件上传功能的时候,企图把所有入口进去的文件上传都要完整演示一遍,到后来根本没有观众愿意关注,都在私下讨论了,有时也会有客户业务人员直接出来制止继续下去。

正确做法:只演示最关键路径

对于多个路径实现相同或相似功能的时候,对其中一条最复杂/重要的路径进行详细演示,其他路径提到即可,并指出其他路径不同的地方,不需要一一演示,以节省时间。

5. 过多提及跟演示功能无关内容

有人天生能聊,showcase的时候也是喜欢啰啰嗦嗦的说一大堆,经常会提及一些跟正在演示的功能无关的东西,或者提及团队采用的技术方案等业务人员不感兴趣的内容,导致showcase过程不能按时结束,甚至有些重要的反馈反而没有收集到。

正确做法:只提及要演示的功能

有时候一个showcase周期内可能开发了一个主要的功能,还有一些小的feedback的改动等,这时候showcase可以考虑只演示最主要的功能,那些小的feedback就不需要show了,也不要提及任何还未完成的功能模块,而且对于团队正在开发的技术卡或者还不成熟的技术方案等,一定不要提及,因为对方是业务人员,不会对技术相关内容感兴趣。

6. 认为showcase仅仅是BA或QA的事情

业务分析师(BA, Business Analyst)和质量分析师(QA, Quality Analyst)通常是团队跟业务打交道最多的,是最了解业务的,而showcase就是给客户的业务团队做系统演示,于是团队其他角色就会有人觉得showcase仅仅是BA或者QA的事情,跟自己无关,也不关注。

正确做法:人人都可以showcase

Showcase不是某个角色独占的,团队所有人只要对业务、对要演示的系统功能足够了解就可以负责showcase,通常可以采用团队不同人员轮换负责showcase方式,以增加团队成员在客户面前的曝光率,同时也能增强团队不同角色人员熟悉系统、熟悉业务的意识。另外,就算不是主导showcase,团队人员也可以尽量的多参加showcase会议,这是一个了解系统、听取客户反馈的非常好的机会。

7. 不熟悉的新人负责showcase

既然showcase不仅是BA或QA的事情,常常也会有其他角色来参与负责这件事情。从团队能力建设的角度考虑,PM有时候会让一些比较junior的同事或者新来不久还没有好好了解系统的同事来做showcase,结果就是演示过程非常生硬,甚至会有很多说不清楚的部分,而在一旁听着的BA/QA着急的只好上来帮忙解释。

正确做法:showcase前先充分了解系统和业务

虽然人人可以showcase,不建议利用给不熟悉的新人提供showcase的机会来提高能力,如果是要给新人锻炼机会,可以让新人在结对编程、Story Kickoff、Desk Check的时候多多的主导,等到对系统和业务有了一定的了解再给客户展示比较好;或者新人非常有意愿直接主导showcase,那么一定要在演示前做好对系统和业务的充分了解,以能应付和解答客户的挑战和疑问。

总结

 专业+高效

前面关于showcase的正确做法都是围绕两个词“专业(Professional)”和“高效(Efficient)”展开的,showcase的目标观众是客户的PO等业务人员,他们是决定是否认可开发团队所开发功能的至关重要的人物,我们在showcase过程中表现出专业性和高效率非常重要。因此,只要记住这两个词,并严格遵循,showcase一定能做好。

产品环境下的QA

2015年11月ThoughtWorks发布的技术雷达提到一个新的主题——产品环境下的QA(QA in Production),2016年4月再次提到。这个主题第一次出现在技术雷达,就深深的吸引了我,当时我就给测试团队成员转发了这个内容,但同时脑子里却产生这样一系列的疑问:

  • 产品环境下的QA可以做什么呢?有什么挑战,又有哪些好处?
  • 它跟类产品环境的QA有何区别,是否就是类产品环境QA方法的延伸?
  • 产品环境有运维支持团队(Ops),产品环境下的QA跟Ops所做的事情又有什么区别与联系?

带着这些疑问,结合项目上的一系列实践,于是有了本文。

一个产品环境Bug的解决办法

先来跟大家分享一个产品环境下的Bug:

一个在线订购葡萄酒的系统,订购流程相对复杂,下单过程中后台会有随机的失败,系统采取的措施是重试,就是说顾客下单后,后台如果有错误就会不停的重试,直到成功,这个过程对顾客是不可见的。这听起来没什么问题,用户体验似乎也不错。

后来有个新版本上线了,顾客下单后还是会有随机失败,系统依然不停的重试,但这次不一样的是有的随机失败,下单却能够成功,这样就导致用户虽然只订购一箱葡萄酒,由于后台的多次重试都成功了,用户最终拿到的可能是好几百箱葡萄酒。

这是一个非常严重且昂贵的Bug!对于这样的问题,作为QA,你能想到的解决办法有哪些?

瀑布式QA流程

瀑布式软件开发模式下,测试是计划驱动的,基本是根据需求文档进行验证,测试的目的就是找到尽可能多的bug,而且测试阶段处于开发阶段结束之后的一个相对独立的阶段,测试结束之后发布产品到产品环境。基本流程如下:

瀑布式QA流程

对于上述葡萄酒订购系统的Bug,通常的办法就是加强在测试阶段的测试保证,除了验证系统功能跟需求文档的一致性以外,还可以增加一些ad hoc测试,确保发布到产品环境的系统尽量的稳定。

敏捷QA流程

敏捷测试则提倡尽早测试、频繁测试,QA要从需求分析阶段就开始介入,QA参与从需求到发布的整个生命周期中各个阶段。在整个QA的过程中,会依据敏捷测试象限,在不同阶段采取不同的测试;还会根据测试金字塔的分层指导,加强自动化测试,制定有利于项目质量保证的测试策略,同时也会做探索性测试,尽量去发现更多不易发现的缺陷。敏捷QA的流程如下:

敏捷QA流程

对于葡萄酒订购系统的bug,处理方式也无非就是加强上线前各个阶段的测试,提高发布到产品环境的产品质量。

除此之外,我们还有什么处理办法呢?

上面两种开发模式下,QA的重点都是放在发布前的类产品环境的质量保证上,而较少考虑产品环境的系统质量。随着敏捷开发和持续交付的出现,QA角色逐渐转变到需要分析软件产品在产品环境下的质量。这需要引入产品系统的监控, 制定检测紧急错误的警报条件,持续质量问题的确定以及找出在产品环境下使用的度量以保证这种方式可行。

回到前面葡萄酒订购系统的那个Bug,如果在产品环境下设置监控预警,对于一个订单购买葡萄酒数量异常的情况进行监控,将能及时发现bug,并且比较容易在损失发生之前及时阻止产生更严重的后果。这就是产品环境下的QA内容之一!

产品环境的特点

为了更好的实践产品环境下的QA,先来分析下产品环境有哪些特点:

1. 真实、不可破坏

产品环境都是真实用户在使用,是真正的支持企业业务运转的系统,不可以随意在产品环境去做测试,尤其是破坏性的测试。

2. 基础设施差异

产品环境往往有着比类产品环境要复杂和健全的基础设施,可能会出现类产品环境不能预测到的缺陷和异常。

3. 系统复杂度

产品环境需要与多个不同的系统集成,系统复杂度会比类产品环境高很多,这种复杂的系统集成很有可能导致一些意外的情况出现。

4. 数据复杂度

产品环境的数据量和数据复杂度也是类产品环境无法比拟的,通常都不是一个数量级的数据,容易引发性能问题、或者一些复杂的数据组合导致的问题。

5. 用户行为千奇百怪

产品环境的用户分布广泛,使用习惯各种各样,导致用户行为千奇百怪,某些使用行为可能就会产生意想不到的问题。

6. 访问受限

产品环境由于是真实业务线上的系统,对安全性和稳定性要求更高,服务器的通常不是所有QA可以随便访问的,这种访问受限的情况对于产品环境的一些缺陷的排查带来了很大的不便。

7. 真实的用户反馈

真实用户在产品环境使用,能够提出一些真实而重要的反馈,但是开发团队往往不能直接接触终端用户,QA也就没有办法获得第一手的用户反馈,这些反馈常常需要通过支持团队的转述。

产品环境的特点

产品环境的这些特点决定了QA在产品环境不是想做什么就能做什么的,原来类产品环境那套质量保证理论和方法都行不通了。

产品环境下的QA有这么多挑战,听起来是不是很沮丧?不要着急,针对产品环境独有的特点,一定能找到相应的解决方案。接下来,咱们一起来看看产品环境下(不仅是QA)可以做什么。

产品环境下可以做什么

一、监控预警

前面讲到不能随便去操作产品环境下的系统对其进行测试,但是可以通过监控的方式去获得我们需要的信息,对异常情况进行预警。提到监控预警,不得不提大家都了解或者至少听说过的日志和网站分析工具,这两者都是做好产品环境下的QA非常有帮助的工具。

监控预警
日志

日志就像是飞机上的黑匣子,可以记录系统运行的各种信息,包括错误、异常和失败等。一旦程序出现问题,记录的这些信息就可以用来分析问题的原因;同时可以利用记录的日志设置好预警,提前预测系统可能出现的问题。产品环境下日志所提供的监控和预警信息,将有利于:

  • 阻止不良后果,避免大的损失:前面提到的葡萄酒订购系统就是一个很好的例子;
  • 发现潜在的性能问题:通过对日志进行分析,可能发现还没暴露出来的性能问题,提前修复;
  • 指导类产品环境的测试:通过产品环境下日志的分析,可以看出哪些功能易出什么样的错误,从而相应调整测试策略,加强类产品环境的相关功能的测试。
网站分析工具

网站分析工具根据具体工具不同,所能记录信息也有差异,但基本都可以记录如下信息:

  • 用户使用的操作系统、浏览器等信息
  • 用户行为习惯,包括使用的时间、关键路径、关键业务流程等
  • 用户所在地区、语言等区域信息
  • 用户访问量,请求的响应时间,网站性能等

利用网站分析工具收集到的以上数据,可以帮助我们调整类产品环境的测试侧重点,指导类产品环境的测试;根据用户行为习惯等信息,还可以帮助优化产品业务价值。

二、用户反馈

介绍产品环境特点的时候提到一点就是产品环境能够收到真实的用户反馈,这是非常有价值的,要做好产品环境下的QA一定要利用这些反馈。由于用户行为和习惯的千奇百怪,用户提供的反馈也可能是各种各样的,为了更好的利用它们,需要一个严格的Triage的过程,对所有反馈进行分类并相应处理。用户反馈,可以总结为下面几类:

用户反馈
缺陷

用户在使用过程中,系统所出现的问题,并且能够稳定重现的,我们定义为缺陷,缺陷通常会影响到功能的使用,是需要修复的,根据优先级和严重程度,安排相应的修复计划并对其进行修复,同时还需要对修复的缺陷增加(自动化)测试,以防被再次破坏。

除了能够稳定重现的缺陷,有时候还会有一些随机的失败(比如前面提到的葡萄酒订购系统的bug)或者难以重现的问题,这类问题很难找到原因,但是又给用户带来很大的不爽。其实,它们通常也是一些缺陷引起的,只是根源可能隐藏的比较深,对于这种问题的处理办法就是前面部分提到的可以添加日志对相关功能进行监控和预警,利用日志协助找到问题根源并进行修复。

抱怨

用户在使用系统过程中由于行为习惯、网络环境等差异,总会有各种抱怨,一般以非功能性的问题居多,比如易用性、性能、可维护性、可扩展性等,当然也有可能是某个功能设计的不能满足真实的用户需求。需要对所有抱怨进行分类,确定是非功能的缺陷,还是新的需求。用户的抱怨有可能千奇百怪,不是所有的都能满足,需要根据分类定义优先级,确定哪些是需要改进和修复,从而采取相应的措施。

建议

除了反馈问题和提出抱怨,用户也会对系统使用方面提一些建议。但一般用户很难提出好的建议,要想收集到有价值的信息,需要提前设计好问卷进行问卷调查,有针对性的去收集;或者对一些重要用户进行访谈,或者发布一个简单的新功能收集用户的使用建议等。然后对收集到的建议进行分析,确定可行性,并将可行的建议应用到后续的系统和业务流程的改进中。

利用用户反馈,改进系统功能,可以优化业务价值,扩大产品的市场影响力,提高企业的竞争力。常被用来收集用户反馈的实践有:

  • Beta测试:很多有前瞻性的网站或应用会发布新功能给特定用户组(Beta用户),收集用户使用新功能的统计数据;
  • AB测试:同时发布两个不同版本的系统到产品环境,并将用户引导到两个版本,统计使用每个版本的用户数据;
  • Observed Requirement:发布一个简单的功能,或者发布一个MVP版本,观察用户使用情况,从而引出并收集到用户的真实需求。

监控预警、收集和分析用户反馈并不是QA能独立完成的,需要与不同角色协作,QA在整个过程中主要充当分析者和协调者的角色,对产品环境下的质量保证工作起到至关重要的作用:

  1. 跟DEV一起讨论监控标准,把日志标准化的要求融入到软件开发流程中,确保日志能够记录到真正需要记录的信息。
  2. 跟运维团队一起分析收集到的统计数据,指导和优化各个阶段的测试,以预防和减少系统在产品环境下的缺陷。
  3. 跟业务分析人员一起分析和梳理从产品环境收集到的需求相关的反馈,提炼出合理的需求,优化业务价值。
QA与不同角色协作

产品环境下的QA在项目上的实践

我所在的项目是一个离岸交付项目,采用的是敏捷开发模式,四周一次发布到产品环境,开发的系统包括一个内部员工使用系统和一个外部用户使用的网站,用户遍及全球,项目整个已经持续了七年有余,产品环境具备前面所描述的所有特点,并且产品环境每日的错误日志达到几千条。正是由于错误日志的数量到了一个不能忍的程度,产品环境引起了各方的关注,也使得产品环境下的QA迎来了试点的最佳时机。产品环境下的QA在我们项目上的实践主要是三部分内容:日志分析和优化、Google Analytics数据分析、用户反馈的收集和分析,下面逐个介绍。

日志分析和优化

既然错误日志那么多,首当其冲就是从这些错误日志下手。项目使用的日志分析工具是Splunk,这个工具功能强大、使用方便,关于工具的详细信息可以参考官网。下图所示为使用Splunk通过指定条件搜索日志文件得到的结果页面,结果集里四条类似乱码的东西就是代表有四种类型的错误日志,每种错误出现的数量和百分比都有统计,点击每条结果可以查看详细的错误日志信息。

Splunk日志分析

关于日志的分析和优化,我们在项目上做了如下工作:

1. 分析产品环境的错误日志

每天会有专人负责错误日志的分析,找出其中的优先级高的问题给团队修复。QA会协助重现、跟踪并负责测试这些重要的需要修复的问题,通过对错误日志的分析,QA可以大概的统计出哪些功能特性比较容易产生错误,在接下来的类产品环境的测试中要重点关注。
另外,对于某些功能由于测试环境的数据等局限性,担心部署到产品环境会产生错误或者有性能问题,一般上线后会着重关注这样的功能,除了日常的监控分析之外,还要单独对该功能的日志进行检查,以防产生严重问题。

2. 监控测试环境的错误日志

把产品环境错误日志的分析方法应用于测试环境,对测试环境的错误日志进行监控,尽量把环境无关由功能引起的错误找出来,尽早修复,不让其流落到产品环境。据不完全统计,最近两三个月通过这种方式发现并修复了好几个潜在的Bug。

3. 利用日志监控不同功能的性能

Ops在Splunk里设置有专门的统计和监控系统性能的Dashboard,QA会定期从里边拿出潜在的存在性能问题的功能模块,创建对应的任务卡由开发团队来做性能调优。

4. 日志记录标准化

通过对产品环境错误日志的分析,发现现有日志记录存在如下问题:

  • 存储位置不统一,有些日志没有办法通过Splunk统计分析,造成分析成本的增加;
  • 记录格式不一致,有些日志虽然可以通过Splunk看到,但是没有记录很有用的信息,比如没有记录错误发生时候的一些有意义的message,或者是Post请求没有记录输入参数,导致排查错误日志的工作增加了难度;
  • 日志级别定义混乱,有些没有到达错误级别(error)的日志也记成了错误(error)日志,这也是错误日志数量大的原因之一。

为了让日志分析更轻松、让日志更全面的记录系统的各种情况,针对上面的问题,团队讨论并达成共识:

  • 将日志输出到各个服务器的同一个路径;
  • 统一日志记录格式,并且尽量记录更全面的信息帮助后期的日志分析;
  • 清晰定义各个日志级别(Debug,Info,Warning,Error,Critical,Fatal),将已有的误记成错误的日志降低到正确的级别,对于新功能则严格按照所定义级别记录日志;
  • QA在用户故事(Story)的开发机验收(Dev-box Testing or Desk Check)阶段负责跟开发人员确认相关日志记录是否符合标准,并且通过测试环境的日志监控可以及时验证新功能的日志记录情况。

Google Analytics数据分析

Google Analytics(以下简称GA)是项目用来统计网站使用情况的工具,从GA上可以获取很多有价值的信息,对这些信息的分析是我们实践的产品环境下QA的另一块内容,具体做了下面几项工作:

1. 操作系统和浏览器使用情况分析

根据GA数据统计分析出用户使用的操作系统和浏览器分布情况,从而相应的调整QA用来测试的操作系统和浏览器,尽量让测试环境跟真实用户更接近。比如,前两年客户内部员工使用的浏览器最多的是IE9,那么我们QA的测试也是主要关注IE9,而今年变成了IE11,我们重点关注的浏览器也相应调整为IE11(当然,鉴于IE9的特殊性——容易出问题,只要还有用户使用,我们还是需要关注),而对于没有用户使用的Firefox,我们则不用来测试。

2. 分析QA测试跟用户真实行为的差异,及时调整测试根据

GA上用户访问的路径可以发现我们QA的测试跟一些真实用户使用习惯的差异,这样如果按照我们通常的路径去测试,可能有些问题难以在测试阶段发现。比如,QA在测试环境通常打开“工作记录”的方式是这样的:

QA测试路径

而我们从GA上发现真实用户使用过程中,打开“工作记录”最多的路径是这样的:

用户使用路径

发现了这种差异,QA就要在测试时候做相应的调整,让测试更接近用户的行为习惯。

3. 提炼关键业务场景,增加测试覆盖

一个开发好几年的系统,其功能必然是比较复杂的,由于自动化测试覆盖率不是很理想,过去回归测试需要的投入比较大,而且由于功能相对复杂,又不是很清楚哪些功能对用户来说最为重要,测试很难做到有效覆盖。这种情况对于人员比例低下的敏捷团队QA来说,是一件非常有挑战的事情,通常QA们在发布前忙得不行。利用GA的数据结合客户业务人员对系统各功能使用情况的介绍,我们提炼出来系统最为关键的一些业务场景,并且尽量分层(参考测试金字塔)实现自动化测试覆盖,从而不需要花费太多的人力去做回归测试,同样可以保证主要的业务流程不至于被破坏,而QA则可以有更多的时间和精力去做探索性测试等更有价值的事情。

4. 发现用户较少使用的功能,优化业务流程

关键场景就是用户使用频率较高的功能,类似的,我们还可以通过GA发现一些用户较少使用的功能,这可能的原因是不符合用户真实行为习惯,喜欢用其他路径去完成同样的事情,或者不符合真实业务需求,也就是说真实的业务环境下根本没有要用到这个功能的地方。对于这种功能,首先从QA角度来讲,我们的测试基本不需要太多去关注,如果有相关功能的缺陷,它的优先级也很低很低;另外,可以跟业务分析人员一起分析下原因,在后续的功能开发过程中可以作为借鉴,从而优化业务流程。

5. 分析用户地区分布和使用时间段分布,合理安排定时任务运行时间

系统用户遍及全球,使用时间段分布也就变得复杂,为了不影响正常使用,有些事情是需要尽量在系统没人使用的时候去做的,比如统计某类数据需要定时执行SQL脚本等定时任务。通过GA上的数据,统计出哪个时间段是相对空闲的,在不影响真实业务的前提下,把一些资源消耗较大的任务安排在那个时候执行,合理分配资源以减轻服务器的负担。

6. 监控系统性能变化趋势,规避性能风险

QA定期查看网站平均访问时间,监控性能趋势,同时要重点关注那些访问非常慢的页面或功能,必要的时候创建性能缺陷卡,由开发人员来调查分析并修复或优化。

7. 确保GA能够统计到所有需要统计的功能

GA数据虽然很有用,但前提是正确记录了所需要统计的数据,所以在开发过程中要确保GA嵌入到了各个需要统计的功能或页面,QA在类产品环境测试的时候需要验证这一点。

下图为从GA拿到的浏览器分布情况和页面平均加载时间的一些数据:

GA统计数据

用户反馈的收集和分析

作为开发团队的我们基本是不能直接接触到系统终端用户的,直接接受反馈的是我们客户的Ops团队,QA主要通过下面几个途径去协助分析和梳理用户反馈:

1. 跟Ops和业务的定期沟通会议

QA会定期跟客户的Ops和业务人员沟通,了解用户对于现有系统的反馈,找出在测试中需要重视的功能特性,将类产品环境的测试关注点做出相应的调整。

2. 培训Ops人员

指导和协助客户Ops人员利用鱼骨图(Fishbone Diagram)的方法对收集到的用户反馈进行分析和分类,将分析结果跟现有的测试覆盖情况进行对比,找出测试过程的薄弱环节,并做出改进。比如,如果某个浏览器出现的bug比较多,而我们的测试则要加强该浏览器的关注;或者是因为不同用户权限导致的问题出现频率高,那就得在测试中注意覆盖不同用户角色的测试,反之则减弱不同用户的覆盖,主要测最常用的那类角色即可。

3. 调查和跟踪产品环境Bug

帮助重现和调查用户反馈过来的产品环境Bug,并负责跟踪修复和验证;对于难以重现的问题,则添加日志监控,通过分析收集到的日志信息找出问题根源,从而进行修复。

4. 协助梳理业务需求

系统要增加某个新功能的时候,客户Product Owner(以下简称PO)或其他业务人员跟用户会一起沟通该功能相关业务现有的使用习惯、使用场景,QA也会尽力参与这种会议,收集用户第一手需求信息,这些信息对于后期该业务功能开发时候的QA过程将非常有帮助。而还有些功能,PO可能一时也拿不定主意要做成什么样子,我们会发布MVP的版本给用户使用,QA协助业务人员分析用户使用后的反馈,梳理更具体的用户需求。

产品环境下的QA有什么特点

1. 不同于类产品环境的QA

产品环境的特点决定了产品环境下的QA是跟类产品环境的QA不同的,不是主动的去测试产品环境的系统,而是通过设置监控条件,收集用户使用系统的反馈,对反馈进行分析并改进,从而让产品质量获得提高。因此,产品环境下的QA并不是类产品环境QA活动的简单后延,它有着自己独特的特点。

2. 不能独立存在

产品环境下的QA所设置的监控标准是根据系统的行为特点和在类产品环境下的表现来定义的,产品环境下各项反馈的分析结果反过来又影响着类产品环境的QA过程,而且这两者是相辅相成的,只有形成了良性环路,才能把产品环境下的QA做好。

良性环路
3. 有别于Ops

产品环境设置监控预警和收集用户反馈不都是Ops团队可以做的事情吗?还要QA参与干什么?那是因为QA有着独特的思维模式和视角,QA的参与能够帮助更好的分析产品环境下收集到的各种反馈,并且结合对于系统的了解,能够将这些反馈更好的应用到日常的开发工作中。

这时候的QA带着QA和Ops的帽子,兼具QA和Ops的部分职责,类似于QAOps,不过现在都提倡不要有独立的DevOps,我们也不要独立的QAOps角色,只是让QA这个角色可做的事情得到了延伸和扩展而已,本质上还是QA。

产品环境下的QA与Ops
4. 跟APM的侧重点不同

可能有人会觉得产品环境下的QA跟APM有相似之处,那么这两者是不是一回事呢?

维基百科这样解释APM

“In the fields of information technology and systems management, application performance management (APM) is the monitoring and management of performance and availability of software applications. (在信息科技和系统管理领域,APM是对软件应用程序的性能和可用性的监控和管理。)”

APM更多的是从性能角度出发去管理和优化应用的可用性,可以发生在各个阶段,不一定是产品环境。产品环境下的QA是指在产品环境进行一系列的监控和数据收集,从系统功能、性能、易用性等多个方面进行优化,从而最终优化业务价值。因此,两者是不同的。

总结

  • 产品环境下的QA将QA的工作范围扩大到从需求到产品环境,增加了更多的反馈来源,跟持续交付结合,可以帮助持续提高产品质量、持续优化业务价值。
  • 产品环境下的QA给QA的工具箱添加了更多的工具,提供了更多评估和提高系统质量的选项,是QA们值得深入研究的话题。
  • 产品环境下的QA不能走的太远,必须先做好类产品环境的质量保证,并且仅适用于持续交付实践的比较好的组织,如果连类产品环境的质量保证都做不好,而就想着去做产品环境下的QA,那只能是舍本逐末、事倍功半。

说起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洞见