去 QE(QE:Quality Engineer)化,就是不要测试工程了,由开发人员编码后自测,这个主题几年前社区中讨论热烈,今天看到相关的贴子,结合最近几年在深圳、北京、上海每年都有的质效相关的大会,想发起跟大家聊聊这个话题。

首先,
去 QE 化这件事是怎么说起的?
据网上消息,这事从 Google 举办的 GTAC 大会说起,GTAC 大会主要围绕测试工程师在自动化测试以及其他的测试技术创新,自 2006 年开始已连续举办了 10 届。可到了 2017 年,Google 突然宣布取消原本计划在伦敦举行的会议,理由是 “相比自动化测试技术,他们更关心工程效能的提升”。

接着,
包括 Facebook,Ebay 等一线互联网公司逐步推行 “没有专职测试,开发自测” 全新模式,向工程效能(Engineering Productivity)团队转型。

初看上去,
“去 QE 化”,未免有些夸张,制造行业焦虑。
其实按我的理解,只要有软件在,就有软件测试的存在。现在是软件定义一切的世界,软件在我们工作、生活的周边,已是处处可见可感受到,软件改变着,甚至颠覆着我们的的工作、生活,如网上购物,微信支付,出行(打车,共享单车)等。由于软件的特性与复杂性,如我们所知,软件是不可能没有 Bug 的,只是我们不可能也没必要把所有 bug 都拦截住。

谈及软件工程效能转型,
完全可以理解,这才是测试成功的方向,因为只有商业的成功,才谈得上测试的成功。想想我们每年都会提,或多或少会做的自动化测试,真正给我们带来多少价值(收益),是否值得老板一直投资,是有待商榷的。但从整个软件开发过程(链路)看,如何提升工作质效,例如自动化或智能化掉开发过程中的某环节或某件事,如随时自动构建软件版本(自动持续集成 CI),并自动进行基本的功能测试(有人也叫自动冒烟测试),自动静态代码检查(提前拦载问题),还有我们都会遇到的项目配置管理,有些公司有专职的配置管理员,软件研发人员申请权限,配置管理员手工开放权限,本身是苦力活,如何自动化掉呢,这些都属于工程效能的问题,也就是说我们要放开视野,不能只盯着测试执行(用例执行)的自动化,更要看到软件开发全过程所有节点的自动化可能,甚至智能化,如用户操作日志的智能分析。你对去 QE 化、工程效能又如何理解呢?


↙↙↙阅读原文可查看相关链接,并与作者交流