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

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

在投入 軟體測試 (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 領域) 從零開始 建立軟體測試團隊，從團隊建立、制度、流程、工程、協作，建立完整的開發流程，其中領悟出最重要的心法就是 品質 的想法，因此寫下以下領悟：

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

簡報與錄影

從理想、到現實的距離，開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813) from Rick Hwang

現場問答

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

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

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

答：請參閱這篇如何量測系統的容量？

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

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

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

答：

如果可以的話，在訪談過程中，讓 QA / Dev 都參與討論，理解需求是需要時間的，所以可以建議一起參與。

敏捷開發有很多框架，像是 Scrum / 看板 / LeSS … etc。其實 QA 要維持的原則沒有變：前期了解需求、針對需求提出想法與疑問、橫向跟 PM / Dev 討論需求。這點其實跟用什麼開發方法沒啥關係。

不會寫程式比較吃虧的是對於非功能測試比較難切入，長期來看，對於培養產品靈敏度，可以延伸發展的方向則是 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 計畫。可能不是測試團隊可以單純搞定的。