质量内建依赖于团队内所有成员的意识和能力，测试人员价值的终极体现是团队赋能，可以从多个维度入手，在产品生命周期的不同阶段，针对不同角色进行持续输出，形成质量思维的规模化，从而从根本上做到质量内建。
“在我的项目背景下，测试人员能发挥能动性的地方不多，测试与上线时间相隔太久，测试人员毫无价值感。”
“测试门槛比较低，技术再好的测试也没有开发技术好，测试人员有什么价值呢？”
“交付是整个产品生命周期的末端，测试更是末端的末端，软件质量好人人有功劳，软件质量差测试要背锅救火，太没成就感了。”
“现在大厂正在裁掉测试部门，测试工作分摊出去或找外包，作为一个测试，我的核心竞争力在哪儿呢？”
“技术日新月异，测试行业水涨船高，对测试人员的知识深度广度要求越来越高，我该怎么提升自己的价值呢？”
上面这些问题来自不同的测试小伙伴，如果正在阅读此文的你也有同样的困惑，那么请跟我一起开启测试人员的价值探索之旅。不论大家身处的开发模式是瀑布还是敏捷，测试人员针对团队的赋能都可以分为三个层面：需求层面、实现层面和组织层面。 下面让我们来逐个探索一下。
需求层面：测试即需求
为什么说“测试即需求”？质量内建的实践之一是测试左移，为了获得更低的缺陷修复成本，测试需要在需求引入阶段就介入，即针对需求的测试。在整个需求产生的过程中，测试人员都可以参与进来，输出自己的想法，贡献自己的业务上下文和测试思路，这种行为对需求最终产生的内容或形式都可能有直接影响，所以我们在某种程度上可以说“测试即需求”。
那么在整个需求产生的阶段，测试人员如何帮助需求正确表达呢？具体的实践有很多：如在需求未明确时，可以帮助业务或产品梳理现有逻辑，提出预期需求；在迭代计划会议和开卡时，可以帮助补充验收标准和支撑性需求，亦或是针对界面交互和用户体验提出改进建议。
讲个段子，假设场景如下：
女友说：“我渴了。”——这是提出了一个需求。
你：“多喝点水。”——毫无求生欲（“两个黄鹂鸣翠柳，我还没有女朋友~” 这种情况不在讨论范围内，测试人员也会帮助明确需求范围）
假如有测试人员，他就会想：“你以为她说的渴了，真的只是渴了么？”，他就会问：“她是在什么情况下说渴了呢？”，与此同时脑子里生成很多分支：
Case1：真的渴了，就是想喝水。——多喝点水。
Case2：逛街有点乏，恰好走到星巴克。——亲爱滴，来杯半糖香草拿铁吧。（不仅满足需求，还了解偏好，体验度加分）
Case3：面试前心里打鼓，有点紧张。——来喝点矿泉水（递过去拧开盖），我的小仙女是最棒的。
Case4：你们没在一起，而你又知道她在哪儿。——你爱喝的 XX 奶茶已经在路上啦，好好照顾自己，我忙完就去找你。
Case5：你们没在一起，你也不知道她在哪儿。——求生欲负值，放过她吧。
等你回复上下文后，测试人员选择合适的路径返回给你。
我们来看一下，在这个过程测试人员做了什么：
需求澄清——基于业务上下文的需求背景分析；
分析现有逻辑——提出现有逻辑的不合理性；
提出预期需求，补充验收标准——针对不同需求背景下的不同验收标准；
提出支撑性需求——递过去拧开瓶盖，下单外卖服务；
关注用户体验——恰到好处的同理心和引导话术。
虽然是个段子，但正是这个简单的段子恰恰说明了测试人员在需求表达、翻译和传递上的价值体现。当他在做这些事的时候（有时甚至是下意识的，来源于测试人员独有的敏感度），不仅可以帮助团队避免由于误解需求造成的浪费和返工，更能让团队内的其他成员 Get 到他所关心的点，从而逐渐建立起需求测试的 Sense，从而帮助用户或客户表达他恰好想要的功能是什么，这就充分体现了测试人员在需求层面的赋能价值。
实现层面：测试即服务
这里所说的“测试即服务”不是指广泛意义上的 TaaS（Testing as a service），其实在某种程度上也可以算是，只不过是来自于自己内部的服务。这里“测试即服务”指的是：测试人员在实现层面赋能的结果是，他提供了一种测试服务，或者测试基础设施。
举个例子，当我们要实现的需求卡是：
在开卡过程中，测试人员可能会问以下问题：
“有没有状态标识一辆车是否有安全座椅？有没有状态标识一个订单是否勾选了宝贝出行选项？”
“这张卡是否包括下单后的车辆匹配？是否包括订单状态更新的显示？”
“如何匹配附近的车辆？就近匹配的算法是什么，有哪些核心的计算逻辑？”
“验收时请演示车辆匹配失败，系统自动重新下单时是否勾选了宝贝出行选项。”
“请为所有分支场景加测试。”
……
两天后，开发完成编码实现，找到测试人员：“我代码写完了想自测一下，怎样快速生成订单？” 测试人员丢过来一个数据生成 SQL 脚本 / 接口 / 工具，告诉开发怎样造测试数据，同时提醒开发务必通过某几个测试用例，反之则不能结卡。
在开卡过程中，测试人员参与了技术讨论，补充了单元测试点，提供了验收用例。在编码实现后（或其他不同阶段），测试人员提供的测试数据、测试用例、测试脚本或工具，都可以帮助开发人员更轻松便捷的完成测试，同时也培养了测试意识（不测过不能结卡嘛）。这就是测试人员在实现层面赋能的价值体现。
组织层面：测试即资产
这一点很好理解。第一，测试人员会进行质量分析，提供测试报告，分析软件质量的变化趋势，分析团队的开发效能，针对流程中不合理的浪费情况提出改进项并跟进，从而使团队的工作方式更加敏捷。第二，测试人员会提前暴露风险，进行风险预警，结合客观条件提出质量预期，帮助团队建立质量信心。第三，测试人员积累了大量业务知识，不管是宏观层面还是业务细节，测试人员对自己测过的产品都了如指掌，往往也更容易成为领域专家。在这个过程中的积累和沉淀，对组织来说都是一种有形的或无形的资产。这就是测试人员在组织层面赋能的价值体现。
总结
佛说，人生有八苦：“生老病死、爱离别、求不得、怨憎会、放下不”，所有的痛苦，不就是因为和预期结果不一致吗？测试工程师这个角色，研究的就是如何让预期和结果保持一致，我们可以采取各种实践，使用各种工具，汇集各种角色，去帮助大家更好的表达预期，实现预期，验证实现的结果与预期是否一致，并记录下来我们努力奋斗的过程，沉淀下来我们智慧凝结的知识。简直不要太有价值感好嘛！本文献给所有挣扎在测试领域的小伙伴们，让我们红尘作伴，快意恩仇。我是QA，我骄傲。
思考题：你认为测试价值的终极体现是什么？哪一点对你来说最重要？为什么?
文/ThoughtWorks于晓南
