请选择 进入手机版 | 继续访问电脑版
我的账户
啄木鸟学院

专注软件测试菁英教育

亲爱的游客,欢迎!

已有账号,请

如尚未注册?

测试人员价值的终极体现

2020-6-30 09:42
原作者: 喜乐本豆 来自: 圆小豆的美梦工场 收藏 邀请

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

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

正文:
  “在我的项目背景下,测试人员能发挥能动性的地方不多,测试与上线时间相隔太久,测试人员毫无价值感。”
  “测试门槛比较低,技术再好的测试也没有开发技术好,测试人员有什么价值呢?”
  “交付是整个产品生命周期的末端,测试更是末端的末端,软件质量好人人有功劳,软件质量差测试要背锅救火,太没成就感了。”
  “现在大厂正在裁掉测试部门,测试工作分摊出去或找外包,作为一个测试,我的核心竞争力在哪儿呢?”
  “技术日新月异,测试行业水涨船高,对测试人员的知识深度广度要求越来越高,我该怎么提升自己的价值呢?”
  上面这些问题来自不同的测试小伙伴,如果正在阅读此文的你也有同样的困惑,那么请跟我一起开启测试人员的价值探索之旅。不论大家身处的开发模式是瀑布还是敏捷,测试人员针对团队的赋能都可以分为三个层面:需求层面、实现层面和组织层面。下面让我们来逐个探索一下。
  需求层面:测试即需求
  为什么说“测试即需求”?质量内建的实践之一是测试左移,为了获得更低的缺陷修复成本,测试需要在需求引入阶段就介入,即针对需求的测试。在整个需求产生的过程中,测试人员都可以参与进来,输出自己的想法,贡献自己的业务上下文和测试思路,这种行为对需求最终产生的内容或形式都可能有直接影响,所以我们在某种程度上可以说“测试即需求”。
  那么在整个需求产生的阶段,测试人员如何帮助需求正确表达呢?具体的实践有很多:如在需求未明确时,可以帮助业务或产品梳理现有逻辑,提出预期需求;在迭代计划会议和开卡时,可以帮助补充验收标准和支撑性需求,亦或是针对界面交互和用户体验提出改进建议。
  讲个段子,假设场景如下:
  女友说:“我渴了。”——这是提出了一个需求。
  你:“多喝点水。”——毫无求生欲(“两个黄鹂鸣翠柳,我还没有女朋友~” 这种情况不在讨论范围内,测试人员也会帮助明确需求范围)
  假如有测试人员,他就会想:“你以为她说的渴了,真的只是渴了么?”,他就会问:“她是在什么情况下说渴了呢?”,与此同时脑子里生成很多分支:
  Case1:真的渴了,就是想喝水。——多喝点水。
  Case2:逛街有点乏,恰好走到星巴克。——亲爱滴,来杯半糖香草拿铁吧。(不仅满足需求,还了解偏好,体验度加分)
  Case3:面试前心里打鼓,有点紧张。——来喝点矿泉水(递过去拧开盖),我的小仙女是最棒的。
  Case4:你们没在一起,而你又知道她在哪儿。——你爱喝的 XX 奶茶已经在路上啦,好好照顾自己,我忙完就去找你。
  Case5:你们没在一起,你也不知道她在哪儿。——求生欲负值,放过她吧。
  等你回复上下文后,测试人员选择合适的路径返回给你。
  我们来看一下,在这个过程测试人员做了什么:
  需求澄清——基于业务上下文的需求背景分析;
  分析现有逻辑——提出现有逻辑的不合理性;
  提出预期需求,补充验收标准——针对不同需求背景下的不同验收标准;
  提出支撑性需求——递过去拧开瓶盖,下单外卖服务;
  关注用户体验——恰到好处的同理心和引导话术。
  虽然是个段子,但正是这个简单的段子恰恰说明了测试人员在需求表达、翻译和传递上的价值体现。当他在做这些事的时候(有时甚至是下意识的,来源于测试人员独有的敏感度),不仅可以帮助团队避免由于误解需求造成的浪费和返工,更能让团队内的其他成员 Get 到他所关心的点,从而逐渐建立起需求测试的 Sense,从而帮助用户或客户表达他恰好想要的功能是什么,这就充分体现了测试人员在需求层面的赋能价值。
  实现层面:测试即服务
  这里所说的“测试即服务”不是指广泛意义上的 TaaS(Testing as a service),其实在某种程度上也可以算是,只不过是来自于自己内部的服务。这里“测试即服务”指的是:测试人员在实现层面赋能的结果是,他提供了一种测试服务,或者测试基础设施。
  举个例子,当我们要实现的需求卡是:

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

  “有没有状态标识一辆车是否有安全座椅?有没有状态标识一个订单是否勾选了宝贝出行选项?”

  “这张卡是否包括下单后的车辆匹配?是否包括订单状态更新的显示?”

  “如何匹配附近的车辆?就近匹配的算法是什么,有哪些核心的计算逻辑?”

  “验收时请演示车辆匹配失败,系统自动重新下单时是否勾选了宝贝出行选项。”

  “请为所有分支场景加测试。”

  ……

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

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

  组织层面:测试即资产

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

  总结:

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

分享本篇文章给更多人:


63.9K
该文章已有0人参与评论

请发表评论

全部评论

这个人很懒,什么也没留下...
粉丝0 阅读935 回复0
关注我们
专注软件测试菁英教育

客服电话:17792550360

客服时间:9:00-21:00

卓目鸟学苑 - 专注软件测试菁英教育!( 陕ICP备20001493号-1 )

版权所有 © 西安菁英教育科技有限公司 2023-2026