扫码阅读
手机扫码阅读

聊聊测试团队在NPS变革中可以做什么

51 2024-01-30

这是鼎叔的第八篇原创文章。

行业大牛和刚毕业的小白,都可以进来聊聊。

11月在MTSC-中国移动互联网测试开发大会,以及深圳敏捷之旅中,鼎叔分享了《提升用户体验的评测方案》议题,本文是其中的部分核心内容,也是该主题下的系列文章第四篇。本文分享测试团队如何拥抱NPS变革的六大落地措施,提供自己擅长的专业价值,同时提升面向体验交付的测试能力。

NPS变革对公司转型如此重要,高级管理者也会身先士卒,作为用户品质的捍卫者,测试团队也应该义不容辞参与其中,而不是做沉默的被动执行者。测试团队具体应该做哪些事,下面给出六个方面的措施案例。积极实践不只是输出关注用户价值的态度,更可以从中获得提升专业水平的灵感。

措施一,分析NPS反馈数据和用户原声,提炼改进动作。

测试人员认真查看NPS反馈数据,可以做二次分析,锁定用户抱怨的TOP问题中可量化测试指标,建立测试度量和改进方案。

  1. 测试团队应该知道如何获取NPS关键数据(在哪查看),如:客服分析/归类报告,反馈者原声记录,NPS埋点指标定义,以及NPS 实时改进系统数据(如有)。

  2. 结合NPS提供的多级标签和反馈占比排名,缩小TOP反馈问题的具体场景,提炼可量化的测试指标,这个可以借助QOE-KQI-KPI标准来完成。
    QOE-用户体验评价,用用户语言及权重来反映,如:游戏很卡,评分5(满分10)
    KQI-关键质量指标,是指标+场景的抽象表达,如:触屏响应时延,应用启动时延等
    KPI-关键分解指标,将抽象体验客观化,有明确的测试场景和执行方法,如:图片预览页面滑动的连续丢帧次数,应用第一次冷启动完成时间,等等。

  3. 如果梳理出了高价值的可持续度量指标TOP N,可以纳入持续监控平台,在看板上监控其变化曲线,如果超过设定阈值则发布告警,甚至可以做竞品对比监控。

  4. 如果用户反馈的问题并非高价值的可持续监控指标(通常是性能指标),而是具体一个功能使用场景的体验,那我们可以判断是否漏测,补充响应的用例,并总结预防该类问题的措施和反思。

  5. 用户的声音在很多时候是含糊不清的,理想情况下需要:

    一,客服或产品经理的回访确认当时的步骤,测试同学根据输入尝试找到复现问题的路径(在有限的投入成本下)。

    二,开发在修复过程中对解决效果进行埋点,上线后做指标对比,同时看用户提出的问题是否已经被修复,如果没有则再次联系相关用户回访。

    三,如果效果达到预期,再根据优先级看下一个TOP N的改进问题。

措施二,参与验收测试,推动体验型交付。

按照常见的研发流程,开发完成自测后,产品经理会做快速的验收测试,确认产品功能符合设计预期,设计师可能会做视觉走查,找到交互设计上有待改进的地方。但是很多公司在验收测试环节的要求是模糊的,甚至当产品经理非常忙碌时,验收成为了形式主义,或者直接忽略。

随着以用户体验为中心的团队价值观的确立,验收测试成为需求完成的必备关卡,纳入迭代完成标准DoD(Definition of Done):所有完成的用户故事必须得到产品Owner的验证。

测试人员虽然不是验收测试的负责人,却是验收测试的受益者,验收测试结束后进入全面测试,可以说验收是后者的子集。越早在验收环节暴露(用户体验)问题,在全面测试的压力就会低很多。

因此我们可以推动产品/设计把验收测试从功能性交付转型为体验型交付,基于体验度量方案,明确验收范围。参考之前阐述的NPS分级标签和QoE测试标准,梳理体验效果的自查测试指标。

首先,明确用户关键路径(KEP),针对本迭代完成的用户故事,用户体验到的关键场景是什么,关键步骤有哪几个,对应的验收测试指标是什么(要求一看就能简单操作完成),如拖动效果符合设计图,发送准确及时,文字图形符合设计要求,等等。

其次,为了确保指标完整覆盖,可以做价值归类,确保每个重要分类都有验收,明确验收角色是产品经理还是设计师。

措施三,利用基础设计规范。

测试人员提报问题的依据,通常是产品设计规格说明书,业务逻辑,质量标准,行业协议规范等等,但是对交互设计存在的问题不太拿得准。实际上,交互设计规范和惯例,理解起来并不复杂,稍做学习和实践就能在一定程度上掌握,提升挖掘问题的敏感度。

首先,各公司通常都有出台产品/品牌设计规范,所有产品都需要参考执行,这个就是我们提报交互类缺陷的依据,通常包括:LOGO的样式/大小的统一使用,重要位置使用字体和大小,菜单颜色搭配规范,轴线对齐要求,页面中呈现选择项的数量和排序要求,结构一致性和风格一致性,操作步骤的可逆性等等,不一而足。

其次,在需求规格说明书中,也会提及设计规范和细节要求描述,可能成为具体测试用例的考察点,如:

  • 该功能输入框的限制条件:范围,大小极限,个数极限,输入框长度极限等。

  • 展示字段的状态:默认态是什么,常见态,特殊态又怎么定义。

  • 操作的反馈效果说明:常见操作,特殊操作,手势操作,错误提示等。

  • 刷新的展示效果:原页面刷新,跳转新页面,如何转场,是否有动画?

最后,在测试过程中细心观察,用于提出类似下述的交互优化建议,积累交互规范的知识和探索手段:

  • 是否有更简单的操作过程,更少的步骤?

  • 是否能让复杂步骤给系统执行(封装),用户只需一键操作?

  • 页面的层次感是否能提升,比如,分层逻辑合理,符合MECE原则(互相独立且被穷尽分类),逻辑相关的放在同一组。

  • 是否有冗余项,干扰选择项?

  • 响应度如何再提升,或者让用户感知更友好? 比如等待较久的操作,用户能一眼看到进展,或者允许其先做其他任务?

  • 产品对于用户的常见操作(正确的或错误的)都有预期处理逻辑。

措施四,配合产品提供体验分级服务的能力。

互联网产品呈现给用户的画面越来越酷炫,但是显示效果也会受机器配置/负载/网络能力等因素的限制,而用户体验的投诉也经常被认为和硬件/网络的情况强相关,这种情况下,软件研发团队可以做什么来改进体验么?

一个可行的思路就是体验分级,或者说动态降级。以手机为例,高中低端的手机,内存/CPU能力差异巨大,中低端机很容易在特效动画/大运算情况下发生卡顿,体验不佳。如果我们质量标准是流畅度必须达标,那很多酷炫效果就难以上线。

因此,我们可以设定用户体验的目标:高端机可以“特效全开,尽情酷炫”,中端机要“关键效果,均衡体验”,低端机要“效果可关,保证流畅”,可以牺牲动效动画等吃资源的功能,简化中间演示步骤。

为了实现上述机制(后台配置或者实时智能选择),产品/开发需要性能基准数据,测试则可以提供:在关键场景下,高中低手机,打开/关闭指定特效,流畅指标值具体是多少。

根据一系列场景的云测试性能数据或现网监控采集,我们就可以联合制定方案,对低端机或中端机,分别建议关闭哪些效果;甚至可以实时监控资源指标,满足什么条件时,该特效功能可以自动启动。

该体验分级方案上线后,观察流畅度数据,可以发现核心页面的流畅达标率明显增加,中低端投诉的相关问题明显减少。

措施五,利用众测挖掘NPS相关问题。

既然用户体验来自典型用户的发声,而采集用户声音的效率是一个难题,当我们有足够多活跃用户的众包平台,就可以借助它完成用户体验的挖掘任务,从分发任务,到核实结果,再到解决问题和奖励用户,低成本完成改进闭环。

众包平台针对用户体验改善可以发布下面几类任务:

  • 灰度产品体验的NPS调查:针对灰度范围的众包用户,填写NPS和建议,作为上市前的NPS预演,提前给产品团队提供参考意见。

  • 用户体验任务:报名参加后,按照链接安装被测产品,及时反馈体验问题并合理归类(标签),经审核后获得积分奖励。

  • 可用性测试:从各类典型用户中招募一定数量的任务参与者(众包平台有典型用户的属性),要求下载使用产品,填写可用性测试调查问卷,助力产品可用性提升。为了保障该测试反馈的有效性,可以要求曾完成该产品测试并提交过有效反馈的用户,或者通过可用性测试知识考试的用户,才能参加问卷调查,并获得可观奖励。

  • (运营)内容质量反馈任务: 针对现网的UGC(用户生成内容)/PGC(专家生成内容)做质量反馈,找出违反平台规定的典型问题,平台核实后进行整改或下架处理,并给予一定的积分奖励。

对于众包平台开展的用户体验任务,如何确保最终的效果(收益)呢?我们可以制定闭环指标来推动达成:

1.       用户体验的有效反馈数/有效反馈率,有效反馈人数等

2.       闭环解决率(用户体验问题状态为已处理/关闭,对于内容质量,“下架”也属于已处理)

3.       问题解决平均时长,平均解决花费等

4.       NPS变化(是否随着版本改进,NPS问卷调查的结果提升?)

措施六,基于ACC模型做测试设计

传统的测试策略和用例设计,都是基于需求规范为出发点,依赖团队经验和个人优先级取舍,这样的测试设计机制就有可能偏离用户视角和用户价值交付。

如果我们从测试设计的框架上就和用户交付价值强绑定,就可以牢牢把控正确的航向,把测试精力聚焦在给用户带来满足感的能力上。

谷歌的ACC模型,就是从用户价值出发指导测试设计的模型,能尽可能避免高用户价值的测试遗漏:

如图矩阵所示,横轴A代表Attributes- 产品交付的核心价值属性(基本价值主张),通常用形容词描述,它也是与竞争对手区别的关键特征。建议测试应和产品经理或业务团队协商明确Attributes(核心价值)有哪些,数量要精,以便在测试策略中区分轻重缓急。

例如,手机浏览器的核心价值(价值观)被设为多快好省,对应的四个attributes可以定义为:多(可获取内容很丰富),快(网站访问速度快),好(高质量内容),省(节省流量和金钱)。

纵轴C:Components,产品的主要模块/子系统或组件功能,可以看做该产品的核心功能清单,通常6个,不超过10个。比如手机浏览器的Components包括首页,资讯频道,小说频道,视频聚合,文件处理能力,内核,设置等等。

这个二维矩阵的每一个交叉格子:C-Capabilities,描述针对某个价值A,在某个模块中,本产品提供了什么具体的能力,从用户视角描述出其场景(具备可测性的)。测试人员就基于此表格进行详细用例设计(通常一个capability就是一个测试对象,或者一个测试情景),或者展开全局探索测试。随着测试的进展,再对ACC矩阵作出必要的调整,进一步优化价值。

总结:测试团队作为用户权益的代表者,积极参与产品/设计师的原型测试,尽早的表达对产品价值的期待。在整个产品软件生命周期,可以成为产品/设计人员的好帮手,助推“用户价值验收”导向。越主动贡献自己的专业见解和“用户视角”的感想,越能获得业务团队的认可。

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483735&idx=1&sn=468404a266468ff7d06a65e6c779b604&chksm=c24fb435f5383d23ee9980909196ef90f69de2bb0ef2e782e9477d85b0e2fc26768840504138#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 5434
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线