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