聊聊测试团队在NPS变革中可以做什么
这是鼎叔的第八篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。
11月在MTSC-中国移动互联网测试开发大会，以及深圳敏捷之旅中，鼎叔分享了《提升用户体验的评测方案》议题，本文是其中的部分核心内容，也是该主题下的系列文章第四篇。本文分享测试团队如何拥抱NPS变革的六大落地措施，提供自己擅长的专业价值，同时提升面向体验交付的测试能力。
参考文章：聊聊用户体验与常规缺陷的异同，聊聊NPS-提升用户体验的终极问题
NPS变革对公司转型如此重要，高级管理者也会身先士卒，作为用户品质的捍卫者，测试团队也应该义不容辞参与其中，而不是做沉默的被动执行者。测试团队具体应该做哪些事，下面给出六个方面的措施案例。积极实践不只是输出关注用户价值的态度，更可以从中获得提升专业水平的灵感。
措施一，分析NPS反馈数据和用户原声，提炼改进动作。
测试人员认真查看NPS反馈数据，可以做二次分析，锁定用户抱怨的TOP问题中可量化测试指标，建立测试度量和改进方案。
测试团队应该知道如何获取NPS关键数据（在哪查看），如：客服分析/归类报告，反馈者原声记录，NPS埋点指标定义，以及NPS 实时改进系统数据（如有）。
结合NPS提供的多级标签和反馈占比排名，缩小TOP反馈问题的具体场景，提炼可量化的测试指标，这个可以借助QOE-KQI-KPI标准来完成。
QOE-用户体验评价，用用户语言及权重来反映，如：游戏很卡，评分5（满分10）
KQI-关键质量指标，是指标+场景的抽象表达，如：触屏响应时延，应用启动时延等
KPI-关键分解指标，将抽象体验客观化，有明确的测试场景和执行方法，如：图片预览页面滑动的连续丢帧次数，应用第一次冷启动完成时间，等等。如果梳理出了高价值的可持续度量指标TOP N，可以纳入持续监控平台，在看板上监控其变化曲线，如果超过设定阈值则发布告警，甚至可以做竞品对比监控。
如果用户反馈的问题并非高价值的可持续监控指标（通常是性能指标），而是具体一个功能使用场景的体验，那我们可以判断是否漏测，补充响应的用例，并总结预防该类问题的措施和反思。
用户的声音在很多时候是含糊不清的，理想情况下需要：
一，客服或产品经理的回访确认当时的步骤，测试同学根据输入尝试找到复现问题的路径（在有限的投入成本下）。
二，开发在修复过程中对解决效果进行埋点，上线后做指标对比，同时看用户提出的问题是否已经被修复，如果没有则再次联系相关用户回访。
三，如果效果达到预期，再根据优先级看下一个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矩阵作出必要的调整，进一步优化价值。
总结：测试团队作为用户权益的代表者，积极参与产品/设计师的原型测试，尽早的表达对产品价值的期待。在整个产品软件生命周期，可以成为产品/设计人员的好帮手，助推“用户价值验收”导向。越主动贡献自己的专业见解和“用户视角”的感想，越能获得业务团队的认可。