测试人员价值的终极体现

如何打造自己的核心竞争力?

开门见山 & 太长不读:

质量内建依赖于团队内所有成员的意识和能力,测试人员价值的终极体现是团队赋能,可以从多个维度入手,在产品生命周期的不同阶段,针对不同角色进行持续输出,形成质量思维的规模化,从而从根本上做到质量内建。

正文:

“在我的项目背景下,测试人员能发挥能动性的地方不多,测试与上线时间相隔太久,测试人员毫无价值感。”

“测试门槛比较低,技术再好的测试也没有开发技术好,测试人员有什么价值呢?”

“交付是整个产品生命周期的末端,测试更是末端的末端,软件质量好人人有功劳,软件质量差测试要背锅救火,太没成就感了。”

“现在大厂正在裁掉测试部门,测试工作分摊出去或找外包,作为一个测试,我的核心竞争力在哪儿呢?”

“技术日新月异,测试行业水涨船高,对测试人员的知识深度广度要求越来越高,我该怎么提升自己的价值呢?”

上面这些问题来自不同的测试小伙伴,如果正在阅读此文的你也有同样的困惑,那么请跟我一起开启测试人员的价值探索之旅。不论大家身处的开发模式是瀑布还是敏捷,测试人员针对团队的赋能都可以分为三个层面:需求层面、实现层面和组织层面。下面让我们来逐个探索一下。

需求层面:测试即需求

为什么说“测试即需求”?质量内建的实践之一是测试左移,为了获得更低的缺陷修复成本,测试需要在需求引入阶段就介入,即针对需求的测试。在整个需求产生的过程中,测试人员都可以参与进来,输出自己的想法,贡献自己的业务上下文和测试思路,这种行为对需求最终产生的内容或形式都可能有直接影响,所以我们在某种程度上可以说“测试即需求”。

那么在整个需求产生的阶段,测试人员如何帮助需求正确表达呢?具体的实践有很多:如在需求未明确时,可以帮助业务或产品梳理现有逻辑,提出预期需求;在迭代计划会议和开卡时,可以帮助补充验收标准和支撑性需求,亦或是针对界面交互和用户体验提出改进建议。

讲个段子,假设场景如下:

女友说:“我渴了。”——这是提出了一个需求。

你:“多喝点水。”——毫无求生欲(“两个黄鹂鸣翠柳,我还没有女朋友~” 这种情况不在讨论范围内,测试人员也会帮助明确需求范围)

假如有测试人员,他就会想:“你以为她说的渴了,真的只是渴了么?”,他就会问:“她是在什么情况下说渴了呢?”,与此同时脑子里生成很多分支:

  • Case1:真的渴了,就是想喝水。——多喝点水。
  • Case2:逛街有点乏,恰好走到星巴克。——亲爱滴,来杯半糖香草拿铁吧。(不仅满足需求,还了解偏好,体验度加分)
  • Case3:面试前心里打鼓,有点紧张。——来喝点矿泉水(递过去拧开盖),我的小仙女是最棒的。
  • Case4:你们没在一起,而你又知道她在哪儿。——你爱喝的 XX 奶茶已经在路上啦,好好照顾自己,我忙完就去找你。
  • Case5:你们没在一起,你也不知道她在哪儿。——求生欲负值,放过她吧。

等你回复上下文后,测试人员选择合适的路径返回给你。

我们来看一下,在这个过程测试人员做了什么: 需求澄清——基于业务上下文的需求背景分析; 分析现有逻辑——提出现有逻辑的不合理性; 提出预期需求,补充验收标准——针对不同需求背景下的不同验收标准; 提出支撑性需求——递过去拧开瓶盖,下单外卖服务; 关注用户体验——恰到好处的同理心和引导话术。

虽然是个段子,但正是这个简单的段子恰恰说明了测试人员在需求表达、翻译和传递上的价值体现。当他在做这些事的时候(有时甚至是下意识的,来源于测试人员独有的敏感度),不仅可以帮助团队避免由于误解需求造成的浪费和返工,更能让团队内的其他成员 Get 到他所关心的点,从而逐渐建立起需求测试的 Sense,从而帮助用户或客户表达他恰好想要的功能是什么,这就充分体现了测试人员在需求层面的赋能价值。

实现层面:测试即服务

这里所说的“测试即服务”不是指广泛意义上的 TaaS(Testing as a service),其实在某种程度上也可以算是,只不过是来自于自己内部的服务。这里“测试即服务”指的是:测试人员在实现层面赋能的结果是,他提供了一种测试服务,或者测试基础设施。

举个例子,当我们要实现的需求卡是:

在开卡过程中,测试人员可能会问以下问题:

  • “有没有状态标识一辆车是否有安全座椅?有没有状态标识一个订单是否勾选了宝贝出行选项?”
  • “这张卡是否包括下单后的车辆匹配?是否包括订单状态更新的显示?”
  • “如何匹配附近的车辆?就近匹配的算法是什么,有哪些核心的计算逻辑?”
  • “验收时请演示车辆匹配失败,系统自动重新下单时是否勾选了宝贝出行选项。”
  • “请为所有分支场景加测试。” ……

两天后,开发完成编码实现,找到测试人员:“我代码写完了想自测一下,怎样快速生成订单?” 测试人员丢过来一个数据生成 SQL 脚本 / 接口 / 工具,告诉开发怎样造测试数据,同时提醒开发务必通过某几个测试用例,反之则不能结卡。

在开卡过程中,测试人员参与了技术讨论,补充了单元测试点,提供了验收用例。在编码实现后(或其他不同阶段),测试人员提供的测试数据、测试用例、测试脚本或工具,都可以帮助开发人员更轻松便捷的完成测试,同时也培养了测试意识(不测过不能结卡嘛)。这就是测试人员在实现层面赋能的价值体现。

组织层面:测试即资产

这一点很好理解。第一,测试人员会进行质量分析,提供测试报告,分析软件质量的变化趋势,分析团队的开发效能,针对流程中不合理的浪费情况提出改进项并跟进,从而使团队的工作方式更加敏捷。第二,测试人员会提前暴露风险,进行风险预警,结合客观条件提出质量预期,帮助团队建立质量信心。第三,测试人员积累了大量业务知识,不管是宏观层面还是业务细节,测试人员对自己测过的产品都了如指掌,往往也更容易成为领域专家。在这个过程中的积累和沉淀,对组织来说都是一种有形的或无形的资产。这就是测试人员在组织层面赋能的价值体现。

总结

佛说,人生有八苦:“生老病死、爱离别、求不得、怨憎会、放下不”,所有的痛苦,不就是因为和预期结果不一致吗?测试工程师这个角色,研究的就是如何让预期和结果保持一致,我们可以采取各种实践,使用各种工具,汇集各种角色,去帮助大家更好的表达预期,实现预期,验证实现的结果与预期是否一致,并记录下来我们努力奋斗的过程,沉淀下来我们智慧凝结的知识。简直不要太有价值感好嘛!本文献给所有挣扎在测试领域的小伙伴们,让我们红尘作伴,快意恩仇。我是QA,我骄傲。

思考题:你认为测试价值的终极体现是什么?哪一点对你来说最重要?为什么?