最近在关注某测试团队的流程规范,发现他们需要依赖很多完善的前置条件,才能有效的开展测试活动。感觉有点不可思议。现在大家都在提倡测试左移,移什么呢?笔者的思考:测试左移,意味着测试思维的转变,我们需要从需求文档中脱离出来,从更广泛的视角来思考测试策略,从技术驱动转变成价值驱动。

01

从文档到业务

在传统测试的环境下,测试人员更多的是围绕需求文档来进测试活动的设计,一切以需求文档为主,关注的是产品的功能需求。而在测试左移的实践中,测试人员需要尝试去理解需求的业务价值,站在用户的角度去思考问题,理解用户的使用习惯、使用场景等信息

在某 API 网关平台的测试中,有这么一个场景:用户在网关平台上配置好 API 信息后,如果想要验证配置是否正确,需要在本地通过 PostMan 发起一次调用,才能确认配置成功。这个场景从功能上而言,是没有问题的。网关平台只负责配置,能否调用是由使用方发起的。如果这么思考,那么体现的就是基于需求文档的思考,因为文档里就是这么描述的。但是如果从业务的角度出发,作为配置方,我希望在配置好 API 信息后,最好能够快速验证,那么,能不能在配置完成的页面增加一个调试功能呢?这样就可以直接在平台上进行验证,而不需要借用第三方工具(PostMan)来验证?

基于这个思考,测试提出了可以在配置成功页面增加一个调试按钮,来直接模拟 API 的调用,如果有异常,还可以直接给出提示,会更友好。最终这个建议被团队采纳,上线后也被用户高度认可,这是他们真实的痛点。

在思考用户场景的同时,从业务的角度出发,我们还需要关注业务操作的流畅性、完整性,同时,对于变更类的需求,还需要评估好影响范围,以用户的身份进行更多的思考和探索。

02

理解业务指标

如果我们想要更好的去了解用户的使用场景,那么我们就需要尝试去理解一些业务型的观测指标,需要确保我们交付的是高价值的内容。业务价值可能比较抽象,似乎不是那么好理解,况且要跟具体的测试活动对应起来更是有些难度,在具体的实践过程中,我们团队的具体做法有几下几步:

  1. 明确业务目标:本次迭代上线的功能是为了满足哪些业务场景,解决哪几类用户的痛点问题,与产品经理、项目经理一起对齐这些目标;

  2. 设计对应的场景:基于业务目标,针对性的设计测试场景,以便覆盖核心场景;

  3. 线上跟踪:基于业务埋点信息、日志系统,查询对应功能的使用频率、用户活跃度的变化,评估需求真实的影响。也可以通过这些数据的分析,得到系统真实的关键功能及核心场景,而不是团队 “以为” 的关键功能和核心场景,进一步优化测试设计。

  4. 回顾、总结:针对线上的收集和反馈出来的数据,定期和产品团队进行沟通、探讨,改进产品设计,优化业务价值。

理解业务指标并不是一件容易的事,需要测试人员对被测试的产品有深度的了解,参与业务对上话。这点是比较不容易实现的,多数情况下,测试人员是比较少能直接接触到用户的。所以,需要我们做好线上数据跟踪和监控。同时,多与产品团队沟通,对齐产品的整体愿景和目标,主动思考。

03

思维上的转变

从基于文档的功能测试,到基于业务的价值测试,需要做更多思维上的转换,从单一的测试角色中走出来,我们的目标不再是高效地发现缺陷(发现缺陷很重要,但不是最重要的),而是快速交付适当质量的业务价值。

认知上的改变:我们不再以发现更多的缺陷为追求目标,应该去理解业务的交付目标是什么,更好的发现和预防缺陷,关注交付价值,合理的设计测试策略,以便快速、高质量地交付迭代内容。

领域知识的增加:更深度地理解你的测试对象,同时去了解同类产品的相关信息,了解用户关心的是什么,了解对应行业的发展信息和最新动态。

沟通表达能力:测试左移让测试人员更多地参与了产品前期的沟通了解,需要有更好的表达能力,传达产品、用户的不同声音,接触更多的人群,所以需要有更好的沟通表达能力,不仅限于技术上的表达,还需要学习业务上的表达技巧。

04

当然,测试左移不是测试角色的一厢情愿,需要团队配合,需要有一定的敏捷成熟度,大家对质量内建有共同的认知。否则,大家都会很痛苦,但这一定是个大趋势。


↙↙↙阅读原文可查看相关链接,并与作者交流