杂文笔记《“去QE”时代下，QE如何破茧重生》

杂文笔记《“去QE”时代下，QE如何破茧重生》

“去QE”时代下，QE如何破茧重生

https://mp.weixin.qq.com/s?__biz=MjM5ODczMDc1Mw==&mid=2651844374&idx=1&sn=8ec218d813d859cce2feeeda62aa5bd6&chksm=bd3d02788a4a8b6e5aaeee226c2caba34e5bc488ee8322711c075aff99616e95d91c72f30b0a&mpshare=1&scene=1&srcid=0620fhgqlTee39PesnsFPz9m#rd

开发自己做测试

“谁开发、谁测试、谁上线、谁On Call”的“一条龙”原则

起因

相比自动化测试技术，他们更关心工程效能的提升

问题

思维惯性

搭建被测试环境以及管理测试执行环境

解决思路

非业务功能开发相关的事务由“工程效能”服务或者相关支持工具链来统一解决

统一测试执行服务

统一测试数据服务

统一测试执行环境服务

构建工程效率工具链仓库

测试即服务（TaaS，Test as a Service）的全局架构

我的看法

在开发与测试岗位上都略有经验。两者的关系、职责、协作等问题都有不断的思考与反思。但还没形成一个完善的思路。

测试岗位上往往有更多不确定的问题需要思考比开发的方案设计与决策，还要更高深更哲学。

我不同意文中去除测试团队的趋势，也不看好所谓的平台/工具链代替测试。

• 文中的思路 统一的XXX，太过理想化，可行性低。
• 引入了复杂的平台与工具，又会陷入‘探索性测试’提出的问题。
  • 如果编写/维护自动化的时间精力远大于测试设计测试执行，那么对于质量还是不是一件好事？

上次看到不需要测试人员，当时流行的思路是TDD。

文章阅读中突然想到一个思路

• 我们提devops强调开发与运维的协调，那么测试在其中扮演什么角色？各家有一些不同的观点。
• 运维维护上线环境与测试维护测试环境，是不是有相通之处？
• 运维上线功能与测试验收功能，有没有相识之处？
• 我想也许运维与测试的沟通可以更多一些。

XMind: ZEN - Trial Version