演講:從理想、到現實的距離,開啟品味軟體測試之路


今天很高興在 台灣軟體工程協會,成功大學 李信杰 老師的邀請之下,讓我第一次分享關於軟體測試的想法與心得。

在投入 軟體測試 (Software Testing)軟體品質 (Software Quality Assurance, SQA) 之前,我主要的工作角色是 軟體開發 為主,程式語言以 PHP / Java / Python、開發大型 Jave Enterprise Application 應用程式與 Eclipse Plugins 為主。過程中因為協助測試團隊改善 Application UI / WebUI 測試,因而踩入測試領域。

因為本身是具備開發背景,踩入軟體測試有別於一般人經歷,因此開啟不一樣的路。實際軟體測試的經歷,包含 WebUI / Desktop UI / Unit Test / E2E … 等自動化測試,設計與開發大型 “Test Framework and Architect for Regression Test“ 實務經驗。

這段經歷讓我對軟體測試的 技術與工程面 有很完整的歷鍊,所以後來也挑戰 在新創事業 (IoT 領域) 從零開始 建立軟體測試團隊,從團隊建立、制度、流程、工程、協作,建立完整的開發流程,其中領悟出最重要的 心法 就是 品質 的想法,因此寫下以下領悟:

品質不只有測試,而是整個 (開發) 過程。
品質從需求開始,測試只是種手段
用品質建立數量,由數量產生速度。

簡報與錄影

現場問答

答: 從了解產品角度切入,了解產品帶給使用者有什麼價值切入。加上 DevOps / SRE 對於系統有了解,所以可以從整合測試切入。

答:我覺得測試工作本質上就要敏捷,也就是主動跟協作對象 (PM / Dev / Ops) 建立溝通的循環。

答:Google軟體測試之道:進行Google級的軟體測試, 簡中

答:請參閱這篇 如何量測系統的容量?

答:請參閱這篇 Software QA 的職能條件

答:如果已經有開發經驗,可以參考我的經歷,從幫忙測試團隊開始,協助改善自動化測試的流程,從過程中取得成就感,真的有興趣再轉。如果是針對 “自動化” 這個技能相關的職能就不只是 QA,DevOps / SRE 也都是大量需要自動化的工作。

答:JMeter、K6、ddosify、apache ab、stress-ng,請參閱這篇 “如何量測系統的容量?

答:

    1. 如果可以的話,在訪談過程中,讓 QA / Dev 都參與討論,理解需求是需要時間的,所以可以建議一起參與。
    1. 敏捷開發 有很多框架,像是 Scrum / 看板 / LeSS … etc。其實 QA 要維持的原則沒有變:前期了解需求、針對需求提出想法與疑問、橫向跟 PM / Dev 討論需求。這點其實跟用什麼開發方法沒啥關係。
    1. 不會寫程式比較吃虧的是對於非功能測試比較難切入,長期來看,對於培養產品靈敏度,可以延伸發展的方向則是 PM / PO 的方向。如果會寫程式,發展方向則會更廣,像是 SDET / SRE / DevOps 甚至 Architect。

答:我在前期算是很幸運,有掌握整個開發流程的核心,前半年算順利。接下來就是團隊磨合期,像是 Dev / QA 雙方對於問題看法的磨合,漸漸模出默契,大家都理解 Spec 很重要,從爭議 / 爭論轉化成討論 / 找到共識,過程大概有半年的長度。

後期 (約第三年的時候) 最大的 bottleneck 就是找到會寫 Code 的 QA,也就是 SDET,隨著產品功能越多,需要 Regression 的範圍就變大,所以有效的保護就重要了,但是實際上要追需要有適當的人到位才行,這時候人才就是關鍵了,不然只能自己跳下去賣肝 XD

答:看公司。不過建議至少要會 shell script、python,能夠寫簡單的自動化測試,像是自動取得 API 資訊,然後篩選資料,丟給下一個 script 處理 … 等。新人我以前面試一定會考三個: shell script 觀念、Linux、SQL、HTML。例如用這些東西自動安裝 Wordpress、確認 Wordpress 安裝完成。

答:不是很確定 內聚性 的意思是什麼,我猜應該是指軟體設計的 高內聚、低耦合 的概念。這在軟體設計階段就需要分析清楚的,通常在 System Design 就會確立每個系統元件的邊界與依賴關係,用程式碼來說就是 OOP 裡,怎樣定義一個 Class,定義好之後,就可以做單元測試。Class 可以做單元測試代表具備一定的內聚力,以及低耦合。

答:大型重構 我猜你的意思是背後的主要結構已經改變,像是 DB Schema 做 Breaking Change、架構做了很大的改變之類的。依照不同層次改動的比例,三者都要有對應的調整。但如果是架構改變,那問題可能就不是測試三角形可以處理的層次,通常要搞定的是 Migration 策略。因為如果是已經在線上跑的服務,需要安排分階段執行以及 Rollback 計畫。可能不是測試團隊可以單純搞定的。

答:大家對於需求或規格認知不一樣的時候,就會討論這個 Bug or Feature?像這張圖一樣:

答:所有角色。

摘錄簡報重點





感謝

兩週前,跟李老師在討論事情,突然說想邀請我分享軟體測試的一些心得。本來想說只有兩週,應該會爆肝,但問了一下 TA 是在學同學,突然一種使命感油然而生,然後就答應了 XDD …. (肝表示 ….)

雖然 Blog 已經有很多素材可以用,不過還是花了一點時間針對在學同學設計內容。每次演講,我都希望帶給聽眾的,不是怎麼去用什麼工具、步驟是什麼,而是聽完之後,能夠有所啟發,這個啟發是過了幾年之後,都依舊受用,這些觀念也是我在 “思考本質、實踐、抽象、想像力“、”學習法則“ 反覆提及的。

這場分享主要 TA 是在學同學與社會新鮮人,構思的時候我就在想:

如果我現在可以回到廿年前,那我想要告訴那時候的我,怎麼做選擇。

所以演講的構思以 “關於軟體測試,一些觀察到的現象“ 為主軸,測試金字塔主要藍圖、”系統測試的三兩事“ 提到的 功能與非功能 為輔助,引導新鮮人啟發探索職涯的可能性。

這次也認識了另外一位講者:Jersey Su,精湛的摘要測試左移的一些脈絡,也告訴同學如何透過探索與刻意練習提升自己,這些想法都讓我非常有感,未來有機會再繼續分享心得~

20230523 更新

本次演將內容,部分收錄在 共同著作《軟體測試實務》 第一冊 第五章之中,歡迎大家彭場指導。


延伸閱讀

站內文章

參考資料



Comments

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲