💭 不分手動與自動，可能是成熟團隊的結果，而不是起點
如題，這篇是在說，不分手動與自動，可能是成熟團隊的結果，而不是起點。 ➼ 很多很猛的團隊不分手動和自動⋯⋯ 沒錯，不少成熟的測試團隊，其實不太會把手動測試和自動化測試劃分成兩種職位，而是要求團隊成員都具備一定的自動化、開發能力，依照需求去做不同的測試工作。 也因此，有些測試團隊在成立的初期，似乎就設定了一個目標：「不分手動和自動」。 這在產品穩定發展、大家能平平順順覆蓋核心場景時，其實都沒什麼問題，但是有些產品可能迎來幾次爆發式的成長，或是過去太順了，一直疏於建立自動化測試，終於有一天就掉進了回歸和手動的泥沼。 我後來覺得，如果今天的目標是「救一個已經陷入測試泥沼的團隊」，明確區分手動與自動，可能是一個有效的做法。 ➼ 先 align 一下認知 手動與自動化測試，本質上都是「測試」這一件事，不過它們分別適合產品與功能的不同階段。 手動測試比較適合負責緊急、零碎、現階段變動較大的工作，例如新功能初期的驗證、需要複雜裝置或網路設定等情境，以及需要一個真實的人類，根據實際狀況判斷「這個功能到底好不好」。 而自動化測試則適合保護關鍵業務邏輯、核心功能、CI/CD 中的 smoke test、覆蓋已經穩定的功能 E2E 流程與回歸測試；在功能開發初期，也可以從核心的 API 邏輯介入。 ➼ 掉進回歸、手動的泥沼 舉兩個我實際遇過的例子。 案例1 團隊為了推動自動化，把自動化測試的人員分散進各個 scrum team，希望每個人都能同時負責新功能的手動測試與自動化。 理想上，這應該會讓自動化更貼近產品。 但實際上，新功能一個接一個進來，手動測試有明確的時程壓力，自動化卻變成「有空再做」。最後不是自動化的人沒有能力做，而是根本沒有時間做。 久而久之，自動化工作開始不斷延期，原本負責自動化的人逐漸失去發揮空間。甚至由於被大量的手動測試工作消耗，選擇離開。 案例2 測試團隊的招募策略是廣招 Staff 等級、擁有很強工程能力的測試進來。 照理來說，這應該會發展成有完整可靠的自動化測試的團隊。 但結果卻是大家每天都忙著手動測試新功能。 因為沒有專門的人承接那些緊急、零碎、需要人工判斷的測試工作，所以每個人都被拉進手動測試的泥沼裡。最後反而變成一個很諷刺的狀況： 一群很會寫程式、也知道應該做自動化的人，卻沒有建立自動化測試。 「所有人都會自動化」和「團隊真的有能力持續建立自動化」，其實是...