回到 2019 年，那時的我們對 Robot Framework 的了解還不夠深入，導致許多測試案例無法平行執行；再加上測試資料管理的不足，進一步加大了測試的複雜度。然而，經過這些年的實踐，我們逐漸找到了應對之道。在撰寫新的自動化測試框架時，我們特別考慮了這些問題，並融入了解決方案。與五年前相比，現在的測試流程更加效率且穩定。 如果你對測試領域有興趣，建議參考我的 Threads，裡面涵蓋了豐富的測試知識、實用技巧和測試思維。若你想深入探討測試議題，例如：測試的學習路徑、敏捷流程的應用，或小型新創公司與大型企業的測試困難點。 前言 在 2019 年初，隨著產品迭代的速度變得越來越快，對於快速釋出新功能變得越來越不容易。當時團隊負責的產品已經是第八版 (2019)，已經累積將近 8000 多個測試案例。 如果要釋出一項新功能，必須花費將近數個禮拜的時間做迴歸測試 (Regression Testing)，除了原本的新功能，還必須重複地執行可能會被影響的舊功能的測試案例，以確保舊功能沒有任何的影響。 於是透過自動化測試保護重要的功能和新功能。最後花費將近一年的時間，將大部分的

最近在 reddit 看到一篇文章(原文連結)，讓我感觸很深。身為新創公司唯一的 QA/SDET，我發現不少人也面臨相同的挑戰。即使有多年經驗，還是會覺得挑戰不小，更何況是剛入行的 QA？這感覺就像是一個新手球隊經理，獨自肩負打造冠軍隊伍的責任，既困難但也充滿機會。 瞭解公司的開發流程 在一間已經有產品上線的新創公司要建立測試流程，第一步是先搞清楚目前的開發流程，看看是否已經有測試機制運作中。也要特別注意開發週期中是否有經常被忽略的環節，這些地方往往是問題最多、最容易在上線後爆發的地方。 如果前期的測試還無法涵蓋大部分的使用者情境，那麼上線後的監控就變得特別重要。確保有足夠的監控機制，能夠即時發現問題、快速修復，這樣才能降低對用戶體驗的影響，並持續優化產品品質。 通常，我會使用測試金字塔模型或敏捷測試象限圖來檢視測試的缺口，確認有哪些地方做得不夠完善，但卻很關鍵部分。這些工具可以幫助我們更有系統地分配測試資源，確保每個環節都有適當的測試覆蓋。 在測試執行方面，一般來說： 單元測試通常由開發人員來寫，如果團隊還沒有這個習慣，可以先鼓勵大家養成撰寫單元測試或整合測試 (API