雜文筆記《「去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