01
从文档到业务
在传统测试的环境下，测试人员更多的是围绕需求文档来进测试活动的设计，一切以需求文档为主，关注的是产品的功能需求。而在测试左移的实践中，测试人员需要尝试去理解需求的业务价值，站在用户的角度去思考问题，理解用户的使用习惯、使用场景等信息。
在某API网关平台的测试中，有这么一个场景：用户在网关平台上配置好API信息后，如果想要验证配置是否正确，需要在本地通过PostMan发起一次调用，才能确认配置成功。这个场景从功能上而言，是没有问题的。网关平台只负责配置，能否调用是由使用方发起的。如果这么思考，那么体现的就是基于需求文档的思考，因为文档里就是这么描述的。但是如果从业务的角度出发，作为配置方，我希望在配置好API信息后，最好能够快速验证，那么，能不能在配置完成的页面增加一个调试功能呢？这样就可以直接在平台上进行验证，而不需要借用第三方工具（PostMan）来验证？
基于这个思考，测试提出了可以在配置成功页面增加一个调试按钮，来直接模拟API的调用，如果有异常，还可以直接给出提示，会更友好。最终这个建议被团队采纳，上线后也被用户高度认可，这是他们真实的痛点。
在思考用户场景的同时，从业务的角度出发，我们还需要关注业务操作的流畅性、完整性，同时，对于变更类的需求，还需要评估好影响范围，以用户的身份进行更多的思考和探索。
02
理解业务指标
如果我们想要更好的去了解用户的使用场景，那么我们就需要尝试去理解一些业务型的观测指标，需要确保我们交付的是高价值的内容。业务价值可能比较抽象，似乎不是那么好理解，况且要跟具体的测试活动对应起来更是有些难度，在具体的实践过程中，我们团队的具体做法有几下几步：
1. 明确业务目标：本次迭代上线的功能是为了满足哪些业务场景，解决哪几类用户的痛点问题，与产品经理、项目经理一起对齐这些目标；
2. 设计对应的场景：基于业务目标，针对性的设计测试场景，以便覆盖核心场景；
3. 线上跟踪：基于业务埋点信息、日志系统，查询对应功能的使用频率、用户活跃度的变化，评估需求真实的影响。也可以通过这些数据的分析，得到系统真实的关键功能及核心场景，而不是团队“以为”的关键功能和核心场景，进一步优化测试设计。
4. 回顾、总结：针对线上的收集和反馈出来的数据，定期和产品团队进行沟通、探讨，改进产品设计，优化业务价值。
理解业务指标并不是一件容易的事，需要测试人员对被测试的产品有深度的了解，参与业务对上话。这点是比较不容易实现的，多数情况下，测试人员是比较少能直接接触到用户的。所以，需要我们做好线上数据跟踪和监控。同时，多与产品团队沟通，对齐产品的整体愿景和目标，主动思考。
03
思维上的转变
从基于文档的功能测试，到基于业务的价值测试，需要做更多思维上的转换，从单一的测试角色中走出来，我们的目标不再是高效地发现缺陷（发现缺陷很重要，但不是最重要的），而是快速交付适当质量的业务价值。
认知上的改变：我们不再以发现更多的缺陷为追求目标，应该去理解业务的交付目标是什么，更好的发现和预防缺陷，关注交付价值，合理的设计测试策略，以便快速、高质量地交付迭代内容。
领域知识的增加：更深度地理解你的测试对象，同时去了解同类产品的相关信息，了解用户关心的是什么，了解对应行业的发展信息和最新动态。
沟通表达能力：测试左移让测试人员更多地参与了产品前期的沟通了解，需要有更好的表达能力，传达产品、用户的不同声音，接触更多的人群，所以需要有更好的沟通表达能力，不仅限于技术上的表达，还需要学习业务上的表达技巧。
04
当然，测试左移不是测试角色的一厢情愿，需要团队配合，需要有一定的敏捷成熟度，大家对质量内建有共同的认知。否则，大家都会很痛苦，但这一定是个大趋势。
