SDET 如何帶給 GoFreight 事半功倍的效率和品質！
by Shawn Huang
在現代軟體開發中，軟體開發測試人員（Software Development Engineer in Test, SDET）扮演著非常重要的角色。這個角色不僅負責確保軟體的品質，還能幫助 Engineering 團隊更加高效地工作。
想要了解關於 SDET 是如何幫助 GoFreight 的嗎？接著往下看吧！
過去：手動為主的 GoFreight
GoFreight 和其他的新創公司沒什麼不同。剛起步時，只有開發人員自己負責測試，等到產品具有一定規模的時候，發現要開發人員同時兼顧開發與測試實在很吃力，於是 GoFreight 便著手找專業的測試人員！此時，測試開始有了初步的分工，由 RD 負責單元測試（Unit-Test）確保程式底層小單元的運行穩定性，QA 則負責從使用者操作介面測試（E2E Test）確保整體功能！
一開始，整個測試團隊只有一位資深的手動測試人員，測試的方法則是單純的手動由使用者操作介面端執行功能測試而已，然而隨著時間過去與公司業績的成長，慢慢的開發團隊越來越大，測試團隊也從一開始的一個人，慢慢成長到二個、三個，而此時測試依然還是以手動測試為主，但產品的功能越來越複雜，程式間的相依性也越來越大！這時團隊意識到單純要依靠手動測試來維持品質實在是太耗費人力與心力了！
轉折：自動化測試萌芽
草創初期的產品每一個功能不大，使用手動測試，簡單的測試計畫寫一寫，手動執行測試難度也不高，專業的手動測試是非常需要經驗的，雖然這樣測試能夠找到關鍵性的 Bug，但是執行起來卻非常花時間，開發端隨便改動一行程式，就需要測試端重新手動測試整個功能一次。
很快地測試部門主管就意識到只有手動測試，是無法持續產出品質與開發速度兼具的產品的，必須要有自動化測試的支持才能確保每個版本基本功能的穩定性。透過手動測試專家的經驗，將這些測試案例改變成能重複執行的程式碼，且不斷在每一個不同版本的程式間重複執行，這樣才能加快新功能的釋出，同時又兼顧系統的穩定性！
此時測試部門主管是唯一一位了解使用者情境，並且懂得寫程式的人，也就順理成章，身先士卒的開發出第一版的自動測試程式，這個初期版本使用 Python + Selenium 的語法，沒有複雜的設計架構，以瀑布式的單純寫法運行，也沒有可重複利用的元件概念。這個元祖自動化測試版本在當時把最重要的測試案例從手動轉換成自動化，正式成為每次版本部署的最後一道防線！
然而由於一開始的自動化測試架構規劃上沒有想太遠，在這種單純架構下跑了一段時間後，我們漸漸發現每次產品的小改版，會需要花很大的力氣去改動相關的自動化測試，此時團隊開始思考我們需要的不僅是自動化測試，而且必須是一個有效率的測試，而該如何規劃也變成了一個重要的議題！
這時候團隊決定找專業的 SDET 進來好好整頓整個自動化測試架構與運作模式，一開始 SDET 花了不少時間在測試與研究各種 Open Source 的自動化測試工具，在多次的來回討論之後，最終我們決定自己開發一套屬於自己的 End-to-End Testing （E2E）自動化測試工具，原因是只有這樣才能針對我們的產品將各種常用的元件以物件化導向的概念開發，既能兼具功能最大化也能達成維運成本最小化的終極目的！
同時我們參考了有名的測試金字塔的概念！測試金字塔通常可分為三層或四層：以四層來說，底層是單元測試，底層往上一層是整合測試亦或是 API 測試，再上層則是端對端測試亦或是系統測試，最後一層則為手動測試。這種結構強調以更多的單元測試為基礎，逐漸擴展到漸少量的更高層次的測試，以提高測試效率和可維護性。因為越往下層的測試越好維護且執行效率高，而越往上層的測試測越難以維護與低效！
現在：自動化測試全面接管產品交付
SDET 團隊就這樣在短短的二個月內將整個工具重新設計，並且把自動化測試加進部署程式版本的 pipeline 中，結合持續整合與交付（CI/CD）的流程，完成了一個全新版本屬於 GoFreight 專用的自動化測試工具，由於這個工具設計最外層為 BDD（Behavior Driven Development）的架構，讓我們整個自動化測試程式既易讀也易寫，在整個開發團隊全體人員加入撰寫後，我們在短短的三個月內完成了約 260 個自動化測試案例，這足以覆蓋我們目前產品的所有重要使用者情境測試！
這些使用者情境測試若是靠一個有基礎經驗的手動測試人員執行一次測試需要 3 至 4 天的時間，使用自動化測試取代並透過平行執行的處理後目前跑完整套測試只需要不到 1 個小時！這足以讓我們在每一次的產品推出前都能再次確保這些重要使用者情境不會出錯！對於產品交付的底氣十足，信心大增！
以測試金字塔的概念來說，一開始的我們只有單元測試和手動測試，而此時的我們測試的涵蓋不僅有了單元測試和手動測試，也補上了自動化的系統測試，並且由於優化了測試工具的架構，使我們可以在短時間大量增加測試涵蓋範圍，這著實解決了當時的一些痛點如：
- 缺乏測試的完整性： 過度依賴手動測試使測試覆蓋不夠全面，導致未能及時捕捉到潛在的問題。
- 手動測試成本高昂： 手動測試通常需要大量時間和人力，成本相對較高，而且容易受到人為錯誤的影響。
- 開發自動化測試進度緩慢：手動測試人員要開發自動測試程式學習門檻高，導致開發進度非常慢。
- 維護自動化測試難度高：程式沒有好的架構與共用元件的概念，導致修改與維護困難度高。
- 部署新版本速度緩慢：由於每個版本的改動都需要手動測試驗證重要功能後才能發佈，導致新版本的部署非常耗時。
挑戰
隨著新的自動化測試大量上線運行，陸陸續續有許多新的難題…如：
- 每次的完整測試需要花費大量的時間，並且其中許多測試案例存在重複的測試步驟。
- AWS 系統不時會出現 worker 中斷的情況，這對我們測試系統的穩定性造成很大的影響。
- 測試案例不夠穩定與可靠，產生假警報造成人力判讀的負擔。
而為了解決上述這些問題，SDET 不停腳持續開發測試任務拆分的功能與並行測試來縮短測試時間，並且開始使用 API 來建立重複性的測試資料，並可允許略過相同 commit 不需再次測試的機制等等！這樣就完了嗎？不！接下來在 GoFreight 我們的 SDET 面臨的任務還很多，包括：
- 如何提高自動化測試系統的效能與穩定性，以更快速、更準確地檢測問題。
- 持續收集系統的各種執行紀錄，並對其進行分析和監控，以便更快地檢測問題。
- 定期觀察每個關鍵測試案例的執行效能，並根據結果分析與回報，與調整測試策略。
- 針對重點 API 和服務間建立端對端的各種測試，確保系統的各個部分都能正常運作。
- 愈來愈多建立的新服務，該如何在 E2E 的環境裡面建立相對應的測試環境。
- 面對 B2B SaaS 複雜的測試資料環境，該如何有效的切換與測試。
隨著新技術的不斷發展，軟體開發測試人員的職責也在不斷變化，這些任務都需要 SDET 具備豐富的技術知識和經驗，以便更好地應對複雜的挑戰。
目標
雖然現在我們已經擁有自己開發的系統測試工具，但我們並不以此自滿，對於未來的目標藍圖也很明確！
我們必須持續開發更有效與可靠的各種測試方案來提升產品的品質，諸如：
- API Test：設計與建構一個適合我們的 API 測試架構來串接各個服務間的整合性測試。
- Security Test：加強系統的安全性，包括漏洞掃描、安全漏洞測試以及授權機制的評估，以確保應用程式的防禦機制足夠堅固。
- Performance Test：進行性能測試，包括負載測試、壓力測試和效能測試，以確保系統在不同使用情境下的穩定性和反應速度。
Last but not least…
軟體測試是產品開發不可或缺的一環，而軟體測試開發人員（SDET）在 GoFreight 公司發展過程中更是不可或缺的重要角色。 SDET 的工作可以接觸廣泛的技術如 Python / Selenium / Docker / Jenkins / AWS 等等，他們為公司產品品質把關，也讓開發更有效率，是技術團隊重要的一份子。
GoFreight 從最初的手動測試，到引入自動化測試， 直到有了 SDET 的加入，自主研發專屬測試工具，讓我們在軟體品質和提高開發效率上有了指數型的成長。雖然實際運行中持續面臨種種考驗，但 SDET 持續的優化測試流程，應對各種技術難題。隨著未來任務的增加，SDET 也必須不斷學習新知識和技能適應不同的工具與框架，以因應複雜的挑戰。
如果你讀完這篇文章對 SDET 有點興趣，我們誠摯的歡迎您跟我們聯繫，期待您加入 GoFreight ! 一起成為航海王的一份子！
