测试需要中台吗?

上一篇 / 下一篇  2022-04-02 10:48:36 / 个人分类:测试

TL;DR, 不需要!

背景

年前老东家裁员,我了解到的是原来不跟业务,纯做测试中台的几个同事基本都躺枪了,而技术不太行但是业务比较熟练的同事都留下了。这一波去中台化就很明显了。

由于我在老东家也做测试中台,结合最近工作的感触,想聊聊这个事儿:测试到底需不需要中台?

测试到底是干什么的

我认为,测试工作的本质,就是平衡质量与效率。为了不出事故,总不能一点儿不测吧;为了能尽快发布,总不能事无巨细的测吧。执行质量和执行效率相同的前提下,用例越多,测试周期越长,质量越高。

但是问题在于,用户会在意产品质量是不是100分么?并不是!精致的用户在意体验,严谨的用户在意稳定,大部分用户只在意能不能用。用户普遍接受90分的质量,那按着90分准出ROI最高。这90分里,通过项目流程、Code Review、RD自测保持到60~70分,剩下的20~30分就是QA的工作。这部分需要通过需求分析用例设计、测试方案设计、测试执行等一系列工作来保证。

比开发更开发,比小白更小白

A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.
First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.
-- Tweet

​QA作为一个“臭挑错的”,既需要了解自己面对的是什么,也要具备跳脱在外的能力。既可以用魔法打败魔法,也可以用热兵器打败魔法。

技术是对工程师的基本要求,而好多人忽略了测试工程师也是工程师。在面试的时候,经常会听到候选人说自动化、测试左移,但是却连需求的技术方案都说不清。如果方案选型都错误了,自动化全覆盖又能怎么样呢?还不是返工重做。一个合格的QA,需要具备一定程度的技术广度,与技术深度占有的RD形成互补。

但是测试作为进入IT行业的“捷径”,具备技术广度的QA非常少。

比产品更产品

我认为这是QA与RD最大的区别。RD的工作是可以脱离业务的,但是QA不可以。站在业务线的角度,需要QA用自己的技术能力快速高质量交付产品,而中台强调的是横向能力、业务无关,所以中台与测试在本质上就相悖。这种前提下拿出来的框架也好、平台也好,在业务里并不好用。我用Puppeteer / Selenium / JUnit / XCTest就可以完成的自动化,为什么还需要你封装一层呢?这一层封装,对我的自动化、对我的业务有什么价值么?

测试中台的成立,占用了技术型QA的HC,这其中又有多少人甘愿回归到枯燥的需求测试中呢?所以回到最开始的背景,如果需要我决定QA团队的裁员名额,虽然不忍心,但我也会把中台放在前面。


TAG:

 

评分:0

我来说两句

Open Toolbar