
杂文笔记《“去QE”时代下,QE如何破茧重生》
“去QE”时代下,QE如何破茧重生
开发本身作测试
“谁开发、谁测试、谁上线、谁On Call”的“一条龙”原则
原由
相比自动化测试技术,他们更关心工程效能的提高
问题
思惟惯性
搭建被测试环境以及管理测试执行环境
解决思路
非业务功能开发相关的事务由“工程效能”服务或者相关支持工具链来统一解决
统一测试执行服务
统一测试数据服务
统一测试执行环境服务
构建工程效率工具链仓库
测试即服务(TaaS,Test as a Service)的全局架构
个人见解
在开发与测试岗位上都略有经验。二者的关系、职责、协做等问题都有不断的思考与反思。但还没造成一个完善的思路。
测试岗位上每每有更多不肯定的问题须要思考比开发的方案设计与决策,还要更高深更哲学。
我不一样意文中去除测试团队的趋势,也不看好所谓的平台/工具链代替测试。
- 文中的思路 统一的XXX,太过理想化,可行性低。
- 引入了复杂的平台与工具,又会陷入‘探索性测试’提出的问题。
- 若是编写/维护自动化的时间精力远大于测试设计测试执行,那么对于质量仍是不是一件好事?
上次看到不须要测试人员,当时流行的思路是TDD。
文章阅读中忽然想到一个思路
- 咱们提devops强调开发与运维的协调,那么测试在其中扮演什么角色?各家有一些不一样的观点。
- 运维维护上线环境与测试维护测试环境,是否是有相通之处?
- 运维上线功能与测试验收功能,有没有相识之处?
- 我想也许运维与测试的沟通能够更多一些。
XMind: ZEN - Trial Version架构