分类目录归档:敏捷

速度(Velocity)不背这个锅

01. 那些对速度(Velocity)的误解

图片来自网络(https://unsplash.com/)

误解1 – 点数跟天数对应?

用户故事的估点跟天数对应,1个点的故事对应2天的工作量;

统计每个用户故事所耗费的天数,如果点数对应的天数到了,先标记为“开发完成”,第二天Desk check就不用增加天数了;

为了赶进度,由结对改为不结对,原来结对的两人并行做不同的task,天数还是按照结对的情况来统计…

问题:

  • 虽然按照故事点来估算,但是每个点都跟天数对应起来,而且不是理想人天,是实际耗费人天;
  • 把这种估算当做一种承诺,要求故事需要在点数对应的天数内完成;
  • 用户故事的只是关注开发完成。

到底该如何估算?点数又该如何使用呢?

误解2 – 做不完了给用户故事涨点?

如果用户故事没有在预定的天数内完成,需要涨点,那么得先说服客户;

列出涨点原因并且跟客户解释不是一件容易的事情,团队有时候宁愿加班加点按照原来的估点完成也不要去跟客户解释…

或者,为了避免以后涨点的各种麻烦,在估算的时候多估一些点,导致估点不准确…

问题:

  • 开发团队的估算不应该受到外部因素的影响;
  • 虚估点导致的估算不准确失去了估算原本的价值和意义。

估算的意义是什么?什么时候需要调整点数进行重估?

误解3 – 速度驱动一切?

周报里的速度保持稳定,每周每对pair在2个点上下;

性能调优,客户觉得目前看不到价值不给点,所以团队就不做了;

技术改进,同样的,客户看不到价值不给点,就不做了;或者团队实在无法忍受想要改进,那就从别的功能用户故事里多估算一些点来留时间给做技术改进;

目前组内开发速度不够,用户故事都做不完了,生产环境的support能给别的组就给别的组做吧,那个太耽误开发进度了!

问题:

  • 一切围绕速度,如果比较顺利,满足了速度要求,团队可能就放松了,不一定会做更多的特性开发;如果不顺利,速度赶不上,那就可能面临着加班或者愁着怎么能给故事涨点以增加速度;
  • 不再是业务价值驱动,不会正常的从价值的角度去考虑工作的优先级,速度被严重的误用。

速度有什么用?又该如何利用呢?

带着这些误解中引发的疑问,我们一起来探讨一下。

02. 两种估算方法

图片来自网络(https://unsplash.com/)

1. 基于故事点的估算

故事点是纯粹对用户故事大小的相对度量,不应该跟任何的天数或者工作量等关联。

用户故事本身的大小属性不会发生变化,基于故事点的估算不会过期,不会受到团队技术能力和业务领域熟悉度的影响而发生变化。比如,一个点数为3的用户故事,它的复杂度相对于那个点数为1的基准故事来说不会发生变化,不管谁、也不管用什么技术来开发这个用户故事。

故事点的大小是指团队所有角色工作加一起的统一估算数值,需要多个角色一起合作讨论才能得出这个估算,因此,故事点的估算方法有利于帮助团队实现跨功能合作的行为。特别注意,不应该按照开发的点数、测试的点数去估算用户故事的大小,需要结合一起给出一个唯一的数值。

2. 基于理想人天的估算

理想人天的估算需要基于这样的假设:

  • 所估算的故事是唯一要做的工作
  • 所有需要的东西在故事开始前都会准备好
  • 故事开发过程中不会被打断。

在不考虑其他因素的情况下,这种理想人天的估算是类似于故事点的估算方法,同样是一种相对大小的估算。

理想时间跟耗用时间是不同的。比如一场NBA比赛的理想时间为12分钟一小节,但是实际比赛耗用时间需要比这个时间长很多,因为中间有暂停、死球等时间。理想人天的估算是基于理想时间的,在软件开发过程中会有多个因素导致实际耗用时间跟理想时间会有很大的不同,比如开会、讨论等。

理想人天的估算方法很容易让人根据一个故事所需完成的任务多少去估算,而不是从这个故事跟其他故事的相对大小角度去考虑;不同人估算的理想人天也会有不同,导致估算可能会不太准确。这在估算的时候是需要特别注意的。

在团队不熟悉故事点估算方法的初期,理想人天的估算方法更容易开始;理想人天的估算对于团队外部人员更容易解释清楚,也更方便预测速度。

哪种方法更好

从前面的介绍可以看到,两种估算方法各有利弊,都是对于用户故事大小的相对度量,不能跟实际完成天数关联起来。通常,更推荐使用故事点的估算方法,根据团队自身情况也可以选择采用理想人天。

03. 什么情况需要重估

前面提到的误解里对于用户故事没有在预定的天数内完成考虑给故事涨点,也就是重估,这种以进度来驱动重估的做法是不对的。没有在估算天数内做完可能有两个方面的原因:
1. 估算不准确,低估了;
2. 被其他工作所打断,或者团队技术原因导致进度较慢…

发现估算不准确的情况可能需要调整,但不能是因为做不完赶不上进度而调整。当所有用户故事的相对大小是准确的时候,不需要重估;只有当其中一个或多个用户故事的相对大小不准确的时候,需要调整该部分用户故事的点数大小。

我们来举例解释这个问题:

1. 不需要重估的情况

假设一个团队有4个复杂度相当的用户故事,原本估算均为3,预计能够在一个迭代完成的。在第一个迭代结束后,只完成了其中的两个用户故事,也就是完成了6个点,团队感觉这两个用户故事比预估的要大,想调整为原来点数的两倍,由6变成12;由于四个用户故事的大小相当,剩下的两个用户故事也需要调整为原来的两倍,剩下的工作量也变成了12,同样的可能还需要一个迭代才能完成。这样的重估就没有意义。

因此,如果只是发现用户故事实际耗费时间比原来预测的要多,但是故事的相对大小并没有问题的时候,不需要重估,而是要去回顾和分析耗费时间长的原因,并采取相应的措施去改进。

2. 需要重估的情况

假设团队由A、B、C、D四个用户故事,刚开始给每个故事的估点均为3。在开发故事A的过程中发现A比原来估算的值要大,需要调整为5才合适,另一个类似的故事B也是一样,需要调整为5;但是C和D跟它们不一样,估算值应该是准确的,还可以保持为3。这种情况下对A和B的重估是有价值的,因为相对大小发生了变化。

图片来自网络(https://unsplash.com/)

04. 速度的作用

速度是对团队的进度生产率的度量,可以通过计算团队在一次迭代中完成的用户故事所分配的故事点数的总和来得到。比如,完成5个3个点的用户故事,速度是15;如果完成了2个5个点的用户故事,速度是10。关于“完成”的定义不能只是到“开发完成”,而应该是“交付完成”,开发完成不能说明什么,可能后续测试还不能过关、有很多缺陷需要修复等情况。

速度可以修正计划的误差。估算把对工作量的估算和对工作时长的估算完全隔离开来,将必须完成的所有用户故事的点数总和除以迭代的速度,可以推算出迭代的次数,也就是项目持续时间。我们通过一个例子来看速度如何修正误差:

假设团队估算出项目中包含了200个故事点的工作,一开始认为可以在每次迭代中完成25点,也就是将用8次迭代来完成工作。但是,在项目开始以后,团队发现速度只能达到20点。这样,不用对任何工作进行重估,就可以正确的认识到项目需要10次迭代,而不是8次。

速度不会是稳定不变的。根据团队对技术和业务领域知识的熟悉程度,速度可能会增加;而随着团队人员调整,有新人加入以后,速度可能会下降。在故事点估算准确的情况下,速度正好是反映团队状态的一个参数。不应该为了保持速度的不变去调整估算的结果,而应该根据速度的变化来观察和分析团队的健康程度。

05. 估算与计划

估算是为了更好的做计划,通过估算推算出的持续时间是一种可能性,而不是对交付时限的一种承诺。估算的是用户故事固有的属性,其大小不应该受到交付时长的干扰。老马在文章《WaterfallProcess》里讲到敏捷开发里的计划应该是适应性的,而预测性的、承诺性的计划不属于真正的敏捷。我们需要认真做好估算,尽量的准确,利用速度并根据团队状态和其他项目因素来适时地调整、修正计划。

适应性计划(https://martinfowler.com/bliki/WaterfallProcess.html)

客户都会希望更短的时间交付更多的功能,但是不要让客户只把目光关注到进度上,要引导客户更多的关注交付的业务价值。因此,在考虑任务的优先级的时候,需要以价值为导向,而不是进度为导向。比如,重构等技术改进、性能调优、生产环境的支持,这些可能比新的特性开发带来的价值更大、有着更高的优先级。

06. 小结

  • 不管是故事点还是理想人天的估算方法,估算的都是用户故事的相对大小,跟实际完成时间没有直接关系。
  • 不能因为用户故事没有在预期的时间内完成而进行重估,只有相对大小发生变化的时候需要重估。
  • 估算是为了更好的计划,不能把估算当做一种承诺;速度是可变化的,可以用来修正计划的误差。
  • 始终要以价值为导向,更多的关注质量而不仅仅是进度,计划应该是可适应性的。

07. 参考文献

  1. 《敏捷软件开发实践:估算与计划》,作者:Mike Cohn,译者:金明
  2. 点之殇》,作者:冉冉,https://insights.thoughtworks.cn/story-point/
  3. WaterfallProcess》,作者:Martin Fowler,https://martinfowler.com/bliki/WaterfallProcess.html

敏捷测试如何优化业务价值

提到敏捷测试就会提到优化业务价值,优化业务价值是敏捷测试的原则之一,敏捷测试的系列活动都要围绕交付价值服务,那么具体的到底要怎么做才能真正优化业务价值呢?

我们需要从四个不同维度来思考和组织相应的测试活动以实现优化业务价值,如下图示:

四个维度
四个维度

01. 从终端用户角度进行测试

从终端用户角度进行测试是基本的测试思维,是测试人员必备的技能要求。

在思考、设计测试用例并执行测试的时候,不能简单的套用用例设计方法去机械的进行,而是要考虑用户可能的行为习惯、使用场景等。

下面来看两个例子:

  • 场景一:我们在使用移动设备的时候,一般会设置自动锁屏。当测试某个移动App时,测试人员觉得移动设备的自动锁屏功能会导致测试很不方便,于是关掉了自动锁屏功能,结果后来在一台测试人员自己使用的设置自动锁屏的手机中发现了一个缺陷,就是在每一次锁屏并开启后,充值选项会新加载一遍,可以导致多个重复的充值选项存在。
  • 场景二:测试移动设备断网的情况,通常会采用调成飞行模式或者关闭数据网络的方式,这两种方式对于iOS7以下的版本通常都需要离开所测的App去设置,这样的操作会导致某些功能不可测或者很多问题不能被发现。如果在移动中测试,也就是说打开App测试过程中,测试人员移动到一个没有网络的地方(比如电梯),将有可能发现很多意想不到的缺陷。

上面两个典型的用户场景都是我们不容忽视的,根据这些真实场景去测试,把自己想象成终端用户,就能容易发现用户可能遇到的问题。

除此之外,还要考虑终端用户的体验,比如说页面的布局、配色、易操作性、页面加载时间等都是在测试过程中需要考虑的因素。这样,有助于交付一个增强用户体验的系统,对优化业务价值是有帮助的。

在敏捷开发生命周期的需求分析、特性启动(Feature kickoff)、用户故事评审、用例设计、故事验收和故事测试等环节都可以体现出从终端用户角度考虑的价值。

02. 以业务为重点的测试

单个终端用户的操作可能只是业务流程的一部分,除了从终端用户角度去测试,还需要看到更高一点,那就是业务流程的合理性、流畅性和完整性。这就要求能够真正理解企业的业务,以业务为重点来测试。

下面来看一个业务流程的简单例子:

  • 某购物网站提供搜索、查看详情、收藏商品的功能,用户可以将看中的商品添加购物车,并下单购买。最初的时候,只能从搜索的结果列表和商品详情页面添加购物车,而收藏是非常重要的一个功能,用户如果想把收藏的商品添加购物车还必须得一个个点开详情页面去添加…
购物流程
购物流程

这个例子中的搜索、收藏、查看详情和添加购物车本身的功能都没有问题,但是从整个流程来看就会发现缺失掉的场景:从收藏列表添加购物车。

敏捷中的用户故事只是覆盖其中某一个非常小的功能,对于用户故事的分析、评审、开发和测试,需要把所有相关故事串起来,甚至需要跟系统其他关联的特性或者第三方系统集成起来看,从整个业务流程角度去思考,以保证整个业务流程的合理性和相关功能的正确性,确保真正满足企业业务需求。

对于复杂业务情况下要发现缺失的路径可能没前面例子那么容易,需要敏捷团队各个角色都能加强这方面意识的培养。QA和Dev都能在敏捷开发生命周期需求分析阶段介入,尽早接触需求,有利于更好的理解业务流程。深刻理解业务流程、以业务为重点的测试,能够更容易发现关键业务流程中遗漏的点或相应的缺陷,测试带来的业务价值又上了一个台阶。

03. 映射业务影响

保证了每个业务流程的流畅性,还需要综合企业多个业务来看企业业务的优先级,能够区分哪些是关键业务和外围业务,要能理解每个业务对于企业的影响、给企业带来的价值。

举例说明:

  • 某公司的系统为税务和移民两块业务服务,在报税忙季,跟报税相关的业务最关键,优先级最高;而在淡季的时候可能报税业务的优先级就要比移民相关业务优先级低。当我们在测试该系统的时候需要关注这种优先级的变化,测试策略上需要有相应的调整。
  • 某公司的系统提供一种通过观看录播视频进行咨询的功能,但是由于制作视频比较费事费力,公司并没有准备马上把这个功能投入使用。这个功能目前并不完善,还有很多要改进的地方,但是由于不是当下的关键业务,它的优先级低了不少。测试人员在测试过程中,也不用投入太多精力去关注这个功能。

在测试过程中需要把系统的质量状况跟业务紧密关联起来,需要能够识别出系统缺陷对业务带来的影响,包括可能影响到的用户数、具体的影响是什么、有没有可以绕过的方法不至于中断业务的开展等。如果影响到最关键的客户,那么相同严重性的bug,对于只影响少量不怎么重要的客户来说,优先级也是完全不一样的。

下面几个方面可以帮助我们开展测试活动的时候更好的考虑业务影响:

  • 定期跟PO等关键业务人员沟通,以保证大家对业务优先级的一致认识,测试策略、测试计划要考虑基于业务优先级来制定。
  • 对于任何代码变更,不能是盲目的无重点的回归测试,要基于业务风险来测。
  • 对于自动化测试,需要权衡成本和收益,更需要基于业务风险来考虑,不能盲目覆盖、事倍功半,要以最小业务风险实现最佳测试覆盖。
  • 利用生产环境下的QA技术,收集生产环境数据并分析,我们可以更好的理解业务关键性和优先级。
映射业务影响
映射业务影响

04. 关联业务指标

除了前面三个维度,在度量项目/产品的测试或质量的时候,不能仅局限于项目/产品范围,要跟企业的业务指标相关联,跟踪、量化测试活动对业务指标的影响。这个维度是非常重要的。

测试不再是考虑发现尽量多的缺陷,而是要基于如何快速将产品投递到市场的战略,尽快让企业能够借助产品盈利。

做到这个维度,需要:

  • 从相关干系人那里确认业务指标,定期跟各干系人沟通,收集对于业务指标的反馈并更新。
  • 收集和分析生产环境的真实数据和模式,反馈到开发过程去更精确的预防缺陷,提高内建质量。

05. 小结

以业务为导向的测试,主要的是思维方式的转变,各个环节要加强对业务的关注。基于前面四个维度去思考,有利于帮助我们把优化业务价值落地。

一页纸测试策略

【摘要】测试策略文档通常是篇幅较长、文字为主的形式,编写成本较高,并且写完了很少有人去看,形存实亡。本文介绍可视化的方式,将测试策略用图来表达,并且在一页纸上搞定,这样的策略图非常清晰,关键信息一目了然,并且提供更大的讨论空间,防止僵化,真正能够发挥策略的作用。


“测试策略是什么样的?”

“测试策略嘛,还不是包括#&~+-=~*-+$这些…”

“你们项目的策略有什么特别的吗?”

“我们项目嘛,测试策略的内容有点多,从哪说起呢?”

前面那个场景有没有似曾相识?你是否清楚目前你们正在使用的测试策略是什么样的?

01. 常见测试策略

测试策略的内容与形式

我们都知道,测试策略包括以下两方面的内容:

  1. 测什么(What)? 测什么是指质量需求是什么、需要关注质量的哪些方面,比如应用的功能范围、性能、安全、易用性等非功能需求。
  2. 怎么测(How)? 怎么测就是采用什么办法来帮助系统实现质量需求,而不仅仅是手动和自动化的测试方法,也包括一切为质量保障服务的流程、环境、基础设施和人员等。

为了描述清楚要测的内容以及如何来测,测试策略通常篇幅较长的文档,包含多个章节;以文字描述为主,只加上少量的配图。

常见测试策略目录结构

【图片来自网络:https://wenku.baidu.com/view/17b9b03067ec102de2bd89ee.html

测试策略的痛点

长篇大论的文字给人带来居多不便:

1. 编写困难

篇幅较长的测试策略文档要写好还真不是件容易的事情,尤其是对于理工科出身的不是那么擅长写作的测试人员来说,更是比较麻烦,成本较高。

2. 不易阅读

长篇大论的测试策略文档,要从中快速找出关键信息可没那么容易,可能一不小心错过的细节就是最关键的部分,因为篇幅太长,通常不太重要的信息挺多的。

3. 维护、更新痛苦

策略文档不可能一成不变,这种篇幅较长的文档要更新和维护简直是噩梦。往往刚开始还好,随着时间推移,更新和维护越来越麻烦。

4. 失去了策略的价值

由于不易阅读,也不易维护和更新,事实上团队可能有很多人并不是很清楚策略文档上的内容,这样的策略文档形存实亡,不能真正起到策略的指南作用。

5. 反敏捷

敏捷开发强调的是缩短反馈周期,快速交付高质量的软件产品。花费太多精力编写、维护一份不能起到策略作用的长篇幅文档,显然是不利于敏捷的,也是非常痛的。

测试策略的重要性不言而喻,是否可以找到一种更好的表达方式,让测试策略不那么痛呢?Jamie McIndoe在“Testing Stuff – A One-Page Test Strategy”中首次提出可以把测试策略图视化,用一页纸来搞定。

我们都知道,图示化的表达方式直观、清晰,容易识别关键信息,并且易于记忆。如果能够用图示化的方法将测试策略在一页纸上搞定,一定非常棒。

下面一起来看看图示化表达的测试策略是什么样的。

02. 图示化测试策略

一页纸搞定

顾名思义,图示化就是用图来描述测试策略的内容,但并不是把原来文字描述的每个章节直接翻译成图。我们考虑用图来表示测试策略的各个关键组成部分,并且绘在一页纸上。

当然,一页纸的测试策略只是将关键信息以图示化的方式呈现出来,并不是整个测试策略的全部,在一页纸的背后是团队的充分沟通和对策略各个方面达成的一致认识,是需要团队一起来做很多工作的。这种高度简化的呈现形式,是为了给团队更多的讨论空间,一页纸也更易于修改,从而更能适应变化,真正满足需求。

基于Jamie McIndoe的可视化测试策略思想,我建议的测试策略图包含下列信息:

  • 指导性原则:团队为质量负责
  • 如何测:测试左移、精益测试、测试右移,涵盖测试流程、测试类型、测试方法等
  • 测什么:包括功能、性能和安全等

下面将以蓝鲸项目为例来介绍这几个部分的内容。关于蓝鲸项目,是一个历经10年的离岸交付项目,采用的是敏捷开发的模式,每四到五周一次发布,遵循敏捷开发的各种实践。

例如,蓝鲸项目的测试策略如下图所示:

蓝鲸项目测试策略图

各部分详细介绍

下面,我们来看看该测试策略各组成部分的具体含义。

1. 指导性原则

蓝鲸项目采用的是敏捷开发模式,质量不是某个单一角色的事情,团队为质量负责是项目质量保障的指导性原则,需要所有团队成员对此有一致的认识,人人都要有关注质量的意识。更多关于团队为质量负责的内容,请参考我的博客文章说好的团队为质量负责呢

2. 测试左移与质量内建

敏捷测试最关键的两点就是尽早测试和频繁测试(Test early, test often),也就是测试左移与质量内建的思想。

测试左移要求在需求分析阶段开始对需求本身的合理性进行验证,不仅要正确的构建产品,更重要的是构建正确的产品,这就需要把好源头需求这一关。因此,我们可以看到策略里的流程是从需求分析开始的。

质量内建则是在软件开发生命周期的每个阶段都有质量相关的活动,把质量融入到开发的每一个步骤,通过CI/CD等方式获取快速反馈,做好软件缺陷的预防,以减轻缺陷暴露太晚带来的大量修复成本。

蓝鲸项目的开发生命周期主要体现在下图的七个环节,每个环节都有相应测试活动的开展,并且每个活动都有不同角色的参与。

蓝鲸项目开发生命周期的测试活动

3. 精益测试

精益测试可以理解为以业务价值为目标,以尽量少的成本交付高质量的软件,也就是说测试要测在能体现价值的点上,要做到有效覆盖、减少浪费。蓝鲸项目的策略图里有两个框架帮我我们更有效的测试,分别是测试象限和测试分层。

测试象限

在Lisa Crispin和Janet Gregory合著的书籍《敏捷软件测试:测试人员与敏捷团队的实践指南》中,我们看到了敏捷测试象限的介绍。由于该象限框架所起到的作用不仅局限于敏捷的环境,我在这里称之为测试象限。

测试象限矩阵一共四个部分,称为四个象限。下侧是面向技术的测试,上侧是面向业务的测试;左侧是支持团队的测试,右侧则是评价产品的测试。

1) 支持团队的测试

支持团队的测试是用来告诉团队要写什么代码,起到明确需求、辅助设计的作用。其中,第一象限是面向技术的支持团队的测试,主要是TDD,帮助构建产品的内部质量,也就是代码质量的保障,比如单元测试和API测试等;第二象限则是面向业务的支持团队的测试,从更高层次以业务专家可以理解的方式确定系统期望的行为,做到产品外部质量的保障。

这两个象限的测试能够快速提供反馈信息,并确保快速的解决问题,既指导了功能的开发,又提供了防止重构和新代码的引入而导致不期望行为发生的安全网。

2) 评价产品的测试

程序员编写的代码可以使得左侧面向业务的测试通过,但也可能没有产生客户真正想要的东西,因此还需要第三、第四象限的评价产品的测试。

第三象限是面向业务的评价产品的测试,通过模仿真实用户使用应用的方式,帮助确认是否构建了真正需要的产品;第四象限是面向技术评价产品的测试,主要采用工具和相应的技术来评价产品的性能、健壮性和安全性等非功能特性,并且在开发周期的每一步都要考虑这些测试的开展。

这两个象限的测试中产生的信息应该反馈到象限矩阵的左侧,并用于创建新的测试来驱动下一步开发,形成良性的增强环路。

3) 测试象限的使用

象限的顺序跟测试执行的顺序无关,敏捷开发往往开始于客户测试(面向业务的测试)。与测试执行时机相关的因素通常有:

  • 产品发布的风险
  • 客户方对产品目标的要求
  • 是基于遗留系统的开发还是从零开始构建的新系统
  • 可利用的测试资源等

测试象限提供一种需要哪些测试来保障质量的思考框架,可以根据项目具体情况,结合考虑以开展对应的测试。策略图所示蓝鲸项目的测试象限体现的测试类型跟Lisa书里介绍的就不太一样,这是根据项目当前跟客户的合作方式、业务需求、质量要求等来确定的当下需要执行的测试,比如其中的安全测试就分为业务部分和技术部分。

测试分层

关于测试分层的思想,大家可能比较熟悉的是测试金字塔,主要是针对自动化测试,根据测试所能覆盖的范围分成不同的层。金字塔的含义是测试比例的多少,体现为底层单元测试较多,越往上层测试比例越少,呈现为金字塔结构。

越往底层的测试越接近代码,编写成本更低、执行速度更快、定位问题也更准确,但是离业务较远,不能很好的体现业务价值;越往上层的测试越接近业务,更能反应业务价值,但有着不够稳定、执行速度慢、实现成本较高的不足。因此,需要权衡利弊,根据项目具体情况,真实的目标来确定每层测试的比例。

至于具体的比例是金字塔结构,还是蜂巢结构或其他,并不是一定的,也不会是一成不变的,可能受到价值目标、痛点、质量要求、技术架构、技能水平等因素的影响。

蓝鲸项目的策略图里的是当前的测试分层结构,类似于蜂巢机构,那是因为基于微服务架构的特点,蓝鲸项目更多的自动化测试是保障服务间连通性的API测试部分,而对于单元测试和端到端测试的比例则都有减弱。更多的关于蓝鲸项目测试策略的详情,请参考我的博客文章微服务测试的思考与实践

4. 测试右移

由于软件系统所处生态环境越来越复杂,技术架构的演进、业务复杂度和数据量的增加、基础设施的发展带来更多的不确定性,软件系统的质量保障在测试环境已经搞不定了,我们需要把目光右移到生产环境。这就是测试右移的思想,其实也就是生产环境下的QA(QA in Production)。

生产环境有着不同于测试环境的特点,生产环境的QA并不是测试环境的QA的直接后延,而是需要利用其特点通过技术手段收集生产环境一切可利用的数据,包括日志、用户行为、用户反馈等,利用这些数据来分析和优化业务以及开发过程的开发和测试工作,形成一个开发过程与生产环境信息分析的良性循环系统。

蓝鲸项目在这方面做了不少工作,更多相关的详细内容,请参考我的博客文章生产环境下的QAQA与Ops通力合作打造反脆弱的软件系统

5. 测什么

之所以把这个放到最后介绍,是因为前面介绍“怎么测”的各个部分都已经涵盖到要测试的内容,蓝鲸项目的测试内容主要有:功能、性能和安全。

这三个方面的测试类似,都是从需求分析到生产环境每个环节都要考虑相关测试,做到质量内建、安全内建和持续的性能测试。关于功能方面的质量内建,前面【测试左移与质量内建】部分有介绍,对于安全和性能方面的策略,可以参考如下图示,由于篇幅有限,本文不做赘述。

蓝鲸项目的跨功能测试

03. 测试策略的正确打开方式

一页纸搞定的测试策略,优势非常明显,比传统策略文档更加简洁、清晰,关键信息一目了然。我们再来看一下测试策略图示化以后,还有哪些需要注意的方面。

目标驱动

虽然上网搜索能找到很多测试策略模板,但测试策略不应该是千篇一律的,不可以死搬硬套通用的模板。测试策略受到多种因素的影响,比如:业务价值、质量要求、当时痛点、技术架构、技术能力、工作重心、绩效要求、项目状态等等。

制定测试策略需要明确目标,综合考虑各种因素,权衡利弊,找到最适合自己项目当前状态的策略。也就是说,测试策略应该是目标驱动的。

演进式

项目处于不同阶段会有不同的质量目标,同时随着架构的演进和业务的发展,对软件系统的质量保障工作也需要随之调整。因此,测试策略还应该是演进式的、随需调整的。

图示化的测试策略是高度精简的,具有更大的讨论和发挥空间,在防止僵化、保持演进方面的优势明显。

04. 总结

测试策略举足轻重,内容很重要,需要以价值目标驱动,持续度量,并根据项目特定情况适时调整、演进。策略文档不要拘泥于形式,利用图示化的方法,直观、清晰的表达,是非常好的组织形式,能有效克服常规文字为主的文档所带来的痛,推荐大家使用。

05. 延伸阅读

  1. Jamie McIndoe的Testing Stuff – A One-Page Test Strategy:https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/
  2. 说好的团队为质量负责呢:https://www.bylinzi.com/2019/07/14/everyone-is-responsible-for-quality/
  3. QA in Production:https://martinfowler.com/articles/qa-in-production.html
  4. 蓝鲸项目测试策略之微服务测试的思考与实践:https://www.bylinzi.com/2018/06/28/microservices-testing/
  5. 生产环境下的QA:https://www.bylinzi.com/2016/06/13/qa-in-production/
  6. QA与Ops通力合作打造反脆弱的软件系统:https://www.bylinzi.com/2018/10/15/qaops/

BQConf演讲:软件测试人员该何去何从?

本文根据11月23日第39届BQConf北京的演讲《软件测试人员该何去何从》整理,为了便于阅读,稍作修改并增加了不同级别的标题。

三个故事

01. 面试中的他

两年前的一个下午,天气有些雾霾,在三楼光线不是特别明亮的会议室里,我和另外一位工作年限跟我差不多的同事面试一位有着10年经验的候选人。

对于跟一位工作十年的候选人见面,我和同事都挺期待,提前沟通好,做好了充分的面试准备。走进会议室,看到一位身材高大、略显疲惫的男士,没有我想象的那种阅历丰富、干练自信的样子。

简单寒暄之后,我们正式进入面试流程。他介绍了自己的工作经历,详细描述了自己这些年所从事的工作的点滴,听下来并没有太多的亮点。出于对候选人负责,我们想尽力去挖掘他的一些加分项,但是,很难,最终无果…

他来自某大公司,多年一直处于一个部门,从事几乎没什么变化的手动测试工作,工作强度不大,对技能要求也不是很高,他在那里做的得心应手。不料,公司业务发展调整,需要部分裁员,他不得不另谋出路。

02. 屏幕那头的她

一年前,我写了一篇文章《微服务测试的思考与实践》。有位朋友看了我的文章,给我发来微信,她觉得我的文章内容对她很有启发,就文章内容跟我进行了咨询和讨论。

她对内容很认可,但是执行起来她觉得没那么容易。我俩聊着聊着,她开始跟我讲她现在的困境:她有简单的编码技能,但是对于更多底层技术、架构方面的知识比较缺乏,在项目团队想推进一些技术变革重重受阻。她做QA也有好些年了,这两年老觉得行业技术更新太快,自己的技术热情和时间有限。而随着工作年限的增加,别人(团队)对她的要求也就更高。

她是一位妈妈,一方面需要照顾家庭和孩子,一方面感觉到工作技能提升的压力,她感觉自己遇到了职业瓶颈。

03. 放弃测试的他们

两个月前,两位好友一起吃晚饭。很久没有相聚,自然是有很多话题聊的。

他们两个都是曾经做测试的,现在分别转做了开发和管理。席间我们聊到了这个话题,身边做QA或者测试的朋友转角色的还不少。我被问到是否考虑转角色的问题,同时,我也听到一个说法:大家都从QA转别的,毕竟QA的地位还是要低一些。

故事讲完了,大家有何感想?

我们来看一下故事里提到的测试人员面临的问题有哪些:

  • 多年重复手动测试,只是关注自己手头的事情,大公司的部门壁垒,跟别的角色、别的团队较少沟通,相对比较封闭。但这些似乎并不影响做好手头的测试工作,觉得自己是“能力够用”的,在这个舒适区待着很爽,自然没有学习提高的动力。
  • 长此以往,应对变化的能力会越来越弱,随着年龄的增长,本应该同样增长的技能却没有相应的增长,感受到外界的压力增加;如果还有身份的变化,成为上有老下有小的夹层,来自家庭的压力导致用于技能提升的精力减少,更加难以提高。
  • 得不到技能的提高,在团队的影响力减小,话语权降低,不被重视,甚至自己也在怀疑所做工作的价值…于是,只好选择换一个角色…

当然啦,有些朋友是真的觉得测试工作不适合自己,转做别的更适合的工作,这些朋友除外。比如跟我吃饭的那两位好友,他们现在都干的很好!

那么,软件测试人员真的有这么悲惨吗?
World Quality Report

由Capgemini、Micro Focus和Sogeti联合组织问卷调查,每年出具一份《World Quality Report》(全球质量报告),今年已经是第10期了。报告列出了大家关注的质量趋势,也会给出一些推荐的做法。报告内容非常多,每期都是70页左右的英文版文档,去年和今年的报告我都有写文章解读,大家感兴趣的可以参考我博客网站上的文章《数字化时代的软件测试》和《关于质量,大家都在关注什么》获取更多细节。

下面来看今年的这份质量报告给我们带来了什么。

我们知道,软件系统首要的是满足功能需求,所以功能是最为核心的内容,但已经不能止步于此,在功能的外层还有更高的质量目标。大家请看图,在功能需求外还有四个方面,分别是:

  • 安全: 信息化时代安全的重要性不言而喻,不仅指应用程序本身的安全、对用户隐私的保护,也包括软件开发过程的安全性和软件资产的安全管理。
  • 速度:互联网时代瞬息万变,都在追求速度上的质量。同样,速度不仅指应用程序本身的性能,也包括交付的速度,从idea到成品交付到用户手里越快越好,抢占先机!
  • 便利性:应用程序能给用户生活提供多大的便利程度,比如说打开一个外卖软件,可以多短的时间找到需要的餐馆,是用户非常看重的一个质量指标。
  • 体验:第四个是用户使用系统的综合体验好坏,易用性、页面的布局和配色等都会影响到用户是否愿意给应用买单。
最高质量目标:终端用户满意度

这四条围绕功能而高于功能的就是终端用户的满意度,是今年质量报告反应出来的大家的最高质量目标!

质量备受关注,对质量的要求越来越高,软件测试或QA工作的重要性不言而喻,我们大家所做的工作毫无疑问是非常有价值的!

同时,随着质量要求的提高,软件测试也不再是发现缺陷那么简单,对我们测试人员的要求也有很大的变化。

为了走出前面故事中的那些困境,我们需要行动起来。

行动起来

01. 学习

面临的问题

显然,最关键的行动一定是学习!说到学习,我们有必要先来看一下大家学习可能面临的问题:

  • 技术日新月异,太多的东西要学,我该从何学起呢?

的确是这样,信息化时代,学习渠道、学习的内容都是无穷的,要学习先要甄别哪一个是值得学的,无疑给学习提高了门槛,这也使得有部分人无从下手,就干脆不学了…

  • 不知道从哪学起,那么我们就先学一个东西再说,学了总比没学好!

这种做法在过去知识比较匮乏的时代,是可取的,学了一定会比没学要好,说不定哪天就能用的上了。但是,现在处在信息化的时代,有些知识是可以不需要花太多精力去学,可以从互联网简单搜索获得的。毕竟精力是有限的,如果花时间学习了这种本可以轻松得来的知识,是很大的浪费。

  • 目的性不强,学到了零散的知识,也很难真正派上用场,最后这个知识还是会被遗忘。

比如说,现在Python很热,小学生都在学Python编程了,觉得我们要还不会就落伍了。可是呢,学了半天,也没有实际用上,过一段时间发现也记不得多少了…这样进行几次之后,会严重影响学习的积极性,发现学了也没用,好像还不如不学。久而久之,就放弃学习了…

学习这么麻烦,我们该怎么学习呢?

学习的过程

我们先来了解一下学习的过程。学习面对的是海量的知识,我们需要从中挑选自己需要的部分,进行加工和提炼,变成自己掌握的知识。到这是不是就结束了呢?并没有。还有最后非常关键的一步,那就是把学到的知识应用到不同的领域,或者总结分享出来供他人学习和使用。

学习的过程

也就是一个完整的学习过程应该包括三个部分,分别是:知识输入、加工提炼、知识输出。缺失其中任何一步,都不是正确的学习。

讲到这里,我想问今天到场的各位朋友一个问题:平常大家都会读很多书,请问大家怎么定义读完了某本书?

答1:我会根据书上介绍的做Demo在团队演示。

答2:我会总结书里的内容在团队分享。

前面两位朋友回答的都非常棒!我想介绍我的一位朋友的做法,他对读完一本书的定义是必须有输出,输出可能但不限于下列的一项或多项:

  • 写读书笔记分享;
  • 提炼书中观点,结合自己的经验总结成博客文章发出;
  • 运用书中理论到工作实践中,在团队以工作坊或小型演讲方式分享;
  • 或者以演讲的方式到大会上分享给更多人。

就是在这样不断反复学习、总结、分享的经历之后,他成为了某技术领域的专家!

学习的正确姿势

了解了学习过程,我们还需要了解学习的正确姿势,以确保学习是真正有效的。关于学习的正确姿势,我认为有两个比较关键的。

首先,根据前面讲的学习过程,最终是要把学到的知识应用起来的。我们可以先搞清楚要把学到的知识应用到哪里,也就是我们学习的目标,搞清楚这个目标,然后利用目标倒逼输入,再进行学习的正向过程,也就是以终为始的做法。

比如:目前工作的项目上需要某项技术,我们有针对性的去学习这一门技术,这样的效果会比较好,能够达到事半功倍的效果。

又或者,目前工作中暂时用不上,但是自己很感兴趣的技术,可以作为学习目标,深入学习和研究,最终的输出可以是集结成文,或者演讲的方式分享出来。这样,不仅可以让他人获益,更重要的是对知识总结提炼的过程,加深了自己对知识的掌握,最获益的还是自己。

目标驱动、以终为始的学习

这就是我要说的第一个正确姿势:目标驱动,以终为始

这里,我们要搞清楚三个问题,也就是

  • Why – 为什么要学?输出是什么?
  • What – 要学什么内容?输入是什么?
  • How – 如何学?学习的方式,对于不同的内容需要采用不同的学习方式。

第二个学习的正确姿势是持续学习。这一点,其实没有太多可讲的,知识在发生着日新月异的变化,现在是特别需要活到老学到老的时代,不然很容易落伍,跟不上变化的步伐。

可能有朋友会说,我在目前工作中的技能已经完全够用了,我也没有很明确感兴趣的方向,该如何提升自己呢?

接下来,我们来看如何确定学习目标的问题。

学习的方向指导

对于目标不是很明确的朋友,不太知道如何从海量知识选择自己需要学习的内容,可以多关注一些趋势性的内容,以此作为自己学习方向的指导。

比如,前面我们提到的全球质量报告(World Quality Report)就是一份很好的趋势方面的内容。

质量报告里提到大家关注的质量趋势集中在五个方面:AI和测试、敏捷和DevOps、测试自动化、环境和数据,以及质量保障方面的成本投入问题,报告分别列出了这几个方面的现状以及未来几年的发展趋势。

同时,报告还给出了一些推荐的应对策略。我们拿其中的质量工程技能方面的策略来详细介绍一下,包括以下几个方面的技能:

质量工程技能策略建议
  • P0 – 敏捷测试专家,包括必备的自动化技能和领域测试技能。敏捷和DevOps的越来越普及,使得对敏捷测试专家的需求成为最高优先级的。一方面,自动化测试是敏捷的基础,要求敏捷测试人员必备自动化技能;另一方面,敏捷测试提倡测试左移,测试人员需要在需求分析阶段开始介入,对领域知识和业务理解能力有相当的要求。
  • P1 – 测试开发技能,处于P1的优先级,要求必备高级自动化、白盒测试、开发技能和平台构建能力,同时,对于AI方面的基础算法应用处理和自然语言处理技能是个加分项。
  • P2 – 接下来的是专项技能集,包括安全、性能等非功能测试、测试环境和数据的管理技能等。前面提到过安全、性能的迫切需求程度,同时报告也指出测试环境和数据的管理水平低下,导致这些专项技能的培养的优先级还是很高的。
  • P3 – 最后一个是高级QA专家,主要是AI架构技能,要求能够构建执行重复、智能任务的“智能测试资产”。鉴于目前AI技术的运用水平,对于这方面技能的培养可以稍缓,但的确是未来的一个发展方向。

下面再给大家推荐一个非常值得关注的技术趋势类读物,那就是ThoughtWorks的技术雷达。ThoughtWorks TAB(ThoughtWorks技术咨询委员会)根据我们在多个行业中的实践案例,每年为技术者产出两期技术雷达,对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。

关于技术雷达,也有朋友说上面跟测试相关的条目越来越少,对测试人员的参考价值不大。我们来一起看一下今年上半年发布的第20期技术雷达。

技术雷达V.20与测试人员关系密切的条目

技术雷达是按照技术、平台、工具、语言&框架四个维度,根据每个维度技术条目的成熟度分成暂缓、评估、实验、采纳四个环。乍一看,带测试字眼的条目较少,但这不代表跟测试相关的内容少。我尝试按如图所示的思维导图的方式做了一个总结,摘出测试人员需要关注的几个方面,并列出对应的技术条目。大的方面有DevOps&基础设施、微服务、自动化测试、线上监控与分析、安全、数据分析与机器学习、区块链等,对于每一块我们都可以相应的思考测试人员需要关注的点有哪些,这里就不详细讲了,更多的细节大家可以参考我的博客文章《软件测试人员的挑战与机遇》。

除此之外,还可以多关注一些技术社区、技术大会、技术类公众号,了解别人都在做什么、有什么新的技术等。相信大家也会有不少这方面的关注,欢迎一起来分享。

02. 沟通

学习是提升自身能力的途径,要想职业生涯更加顺畅,还有很关键的一个行动是需要增加跟他人的沟通,不可以独自处于封闭的状态下闷头学习。

首先,项目团队内跟不同的角色的沟通

我们一直在讲团队为质量负责,但是团队不同的角色对质量的理解可能不够透彻、对质量关注的意识也会不太够,作为团队的QA,是需要承担起质量协调者的角色的,需要把自身对质量的理解、当前项目产品的质量状态及时的跟团队反馈,需要跟不同角色有足够的沟通,让团队不同的角色能够更好的一起为质量负责。

当下流行的全流程测试,更是强调测试人员在各个环节的参与,跟不同角色的合作,比如说需求分析阶段需要跟业务分析人员合作,自动化测试需要跟开发人员合作,在生产环境下的QA又需要跟Ops的人员合作等。

在跟不同角色的合作过程中,不仅可以从对方角色那里学习到自身欠缺的技能,以丰富自身能力;同时,也可以让跟你合作的角色从你身上学习到测试考虑的角度,更好的做好质量的每一步。这是一个双赢的过程,1+1>2。另外,合作多了,大家也走得更近,工作更好开展,自然在团队的影响力就会增加,地位感也随之增加了。

团队内跨角色沟通

其次,更大范围的沟通

项目团队的充分沟通,有利于项目工作的顺利开展,但是,团队还是太小,需要扩大到更大范围。比如说,多参与技术社区、技术大会、技术讨论微信群等。相信今天来到现场的朋友们都是体会到这个方面的优势的,都非常积极的参会。

这里,我们要注意一点,如果只是看或者听别人分享的话,参与感是不太够的,效果不会太好。要多发表自己的看法,或者抛出自己的疑问,多跟人沟通,不是单向的吸收。除了一对一沟通,可以参与群体的讨论,或者对一些技术文章、所读书籍发表评论、读后感,还可以通过写文章、演讲的方式分享自己的经验所得。

请记住,有输出才会有收获。这个非常关键!

03. 突破

刚接触测试的从业人员,可能非常关键的一项技能就是要能尽可能的发现bug,于是我们有着很大的一个优势就是比较容易发现很多细节上的问题。这也同样带来一个问题,那就是有的测试人员过度关注细节,导致工作好几年还是容易抠细节,看不到大局。因此,我们的第三个行动是需要跳出来,做到突破,要有破局思维!

突破

首先,要培养系统思考能力。世间万事万物都是有联系的,构成众多大小不一的系统。

小的系统比如目前正在做的产品,当你发现某个功能有bug的时候,它真实的问题可能出在另一个你想象不到的模块,这个时候如果只是停留在你发现问题的模块,可能就浪费很多时间也难以定位问题;或者你发现一个bug,觉得它很严重需要紧急修复,但是当你结合市场情形、业务发布优先级、对终端用户的真实影响、修复所需成本以及开发人员手头其他工作的优先级综合来看,最后可能发现那个bug的优先级低了很多…

这是系统思考的两个简单的例子,由于系统思考不是我今天要讲的重点,在此就不多讲了。大家感兴趣的可以找相关资料,运用前面所介绍的学习方法去获取相关知识。

其次,需要扩大视野。前面讲到的关注技术趋势、参加技术讨论等都是扩大视野的途径。通过吸收这些信息,视野变大了,个人看问题的角度就会变的不一样,也就更容易去发现问题或者提出建设性的解决方案。

最后,遇到问题时,要运用系统思考的能力,跳出单一的小系统,利用曾经吸收到的各类有价值的信息,逐步建立自己的大局观

这几点,我认为都是测试人员非常需要培养的能力,也是帮助我们拓宽职业之路的有力助手。

前面讲到这么多,有些是通用的适合所有人,但是,我们还是需要结合自身特点去选择适合自己发展的方向和提升的方法,要结合自己的兴趣特长、性格特征来选择。如果没有跟自己兴趣特点匹配的也不用太过担心,相信兴趣特点也是可以培养的。我想送大家两句话:

选自己所爱,爱自己所选!

坚持就是胜利!

回顾与总结

今天通过三个我亲身经历的故事,我们看到了测试人员可能面临的问题。同时,给大家分享了我们可以采取的三个行动。最后总结一下,希望大家能够记住下面几个关键词:

  • 以终为始,持续学习
  • 沟通交流,让知识翻倍
  • 勇于突破,系统思考
  • 选自己所爱,爱自己所选

今天分享的这些是我在学习、摸索中的一些总结,我不是什么成功人士,所以这也只是抛砖引玉,希望大家更多的来一起分享和讨论,愿我们各位测试同仁们都有一个好的职业发展的明天!

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

问:谁应该为质量负责?
答: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们共享信息的意识得到了加强,日常工作中遇到某种情况觉得其他团队需要知道的就会主动分享出来。

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

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