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

本文转自【林子的空间】

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

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

四个维度

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

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

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

下面来看两个例子：

• 场景一：我们在使用移动设备的时候，一般会设置自动锁屏。当测试某个移动App时，测试人员觉得移动设备的自动锁屏功能会导致测试很不方便，于是关掉了自动锁屏功能，结果后来在一台测试人员自己使用的设置自动锁屏的手机中发现了一个缺陷，就是在每一次锁屏并开启后，充值选项会新加载一遍，可以导致多个重复的充值选项存在。

• 场景二：测试移动设备断网的情况，通常会采用调成飞行模式或者关闭数据网络的方式，这两种方式对于iOS7以下的版本通常都需要离开所测的App去设置，这样的操作会导致某些功能不可测或者很多问题不能被发现。如果在移动中测试，也就是说打开App测试过程中，测试人员移动到一个没有网络的地方（比如电梯），将有可能发现很多意想不到的缺陷。

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

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

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

02. 以业务为重点的测试

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

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

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

购物流程

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

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

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

03. 映射业务影响

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

举例说明：

• 某公司的系统为税务和移民两块业务服务，在报税忙季，跟报税相关的业务最关键，优先级最高；而在淡季的时候可能报税业务的优先级就要比移民相关业务优先级低。当我们在测试该系统的时候需要关注这种优先级的变化，测试策略上需要有相应的调整。

• 某公司的系统提供一种通过观看录播视频进行咨询的功能，但是由于制作视频比较费事费力，公司并没有准备马上把这个功能投入使用。这个功能目前并不完善，还有很多要改进的地方，但是由于不是当下的关键业务，它的优先级低了不少。测试人员在测试过程中，也不用投入太多精力去关注这个功能。

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

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

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

映射业务影响

04. 关联业务指标

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

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

做到这个维度，需要：

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

05. 小结

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