关于不要测试工程师 (去 QE 化）与工程效能的问题

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

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

接着，
包括 Facebook,Ebay 等一线互联网公司逐步推行 “没有专职测试，开发自测” 全新模式，向工程效能（Engineering Productivity）团队转型。文章源自玩技e族-https://www.playezu.com/186382.html

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

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

下载功能测试 软件测试文章源自玩技e族-https://www.playezu.com/186382.html 文章源自玩技e族-https://www.playezu.com/186382.html