标签归档:敏捷测试

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

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

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

四个维度
四个维度

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

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

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

下面来看两个例子:

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

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

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

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

02. 以业务为重点的测试

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

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

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

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

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

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

03. 映射业务影响

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

举例说明:

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

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

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

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

04. 关联业务指标

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

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

做到这个维度,需要:

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

05. 小结

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

聚焦测试,驱动卓越

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

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

测试原则

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,以做到持续的改进和优化。

总结

图片来自网络

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

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