💭 不分手動與自動，可能是成熟團隊的結果，而不是起點

如題，這篇是在說，不分手動與自動，可能是成熟團隊的結果，而不是起點。

➼ 很多很猛的團隊不分手動和自動⋯⋯

沒錯，不少成熟的測試團隊，其實不太會把手動測試和自動化測試劃分成兩種職位，而是要求團隊成員都具備一定的自動化、開發能力，依照需求去做不同的測試工作。

也因此，有些測試團隊在成立的初期，似乎就設定了一個目標：「不分手動和自動」。

這在產品穩定發展、大家能平平順順覆蓋核心場景時，其實都沒什麼問題，但是有些產品可能迎來幾次爆發式的成長，或是過去太順了，一直疏於建立自動化測試，終於有一天就掉進了回歸和手動的泥沼。

我後來覺得，如果今天的目標是「救一個已經陷入測試泥沼的團隊」，明確區分手動與自動，可能是一個有效的做法。

➼ 先 align 一下認知

手動與自動化測試，本質上都是「測試」這一件事，不過它們分別適合產品與功能的不同階段。

手動測試比較適合負責緊急、零碎、現階段變動較大的工作，例如新功能初期的驗證、需要複雜裝置或網路設定等情境，以及需要一個真實的人類，根據實際狀況判斷「這個功能到底好不好」。

而自動化測試則適合保護關鍵業務邏輯、核心功能、CI/CD 中的 smoke test、覆蓋已經穩定的功能 E2E 流程與回歸測試；在功能開發初期，也可以從核心的 API 邏輯介入。

➼ 掉進回歸、手動的泥沼

舉兩個我實際遇過的例子。

案例1

團隊為了推動自動化，把自動化測試的人員分散進各個 scrum team，希望每個人都能同時負責新功能的手動測試與自動化。

理想上，這應該會讓自動化更貼近產品。

但實際上，新功能一個接一個進來，手動測試有明確的時程壓力，自動化卻變成「有空再做」。最後不是自動化的人沒有能力做，而是根本沒有時間做。

久而久之，自動化工作開始不斷延期，原本負責自動化的人逐漸失去發揮空間。甚至由於被大量的手動測試工作消耗，選擇離開。

案例2

測試團隊的招募策略是廣招 Staff 等級、擁有很強工程能力的測試進來。

照理來說，這應該會發展成有完整可靠的自動化測試的團隊。

但結果卻是大家每天都忙著手動測試新功能。

因為沒有專門的人承接那些緊急、零碎、需要人工判斷的測試工作，所以每個人都被拉進手動測試的泥沼裡。最後反而變成一個很諷刺的狀況：

一群很會寫程式、也知道應該做自動化的人，卻沒有建立自動化測試。

「所有人都會自動化」和「團隊真的有能力持續建立自動化」，其實是兩件完全不同的事情。

要讓團隊有能力持續建立自動化，是職責與資源配置的問題。

➼ 還沒有穩固的測試基礎

為什麼會掉進手動的泥沼？因為團隊還沒有穩固的測試基礎。

這邊舉一些具體的例子。

假設今天有一個網站，已經存在 Google、Facebook、Email 等多種登入方式，現在又要增加一種新的登入方式。

最理想的情況，是既有的登入方式早已被自動化測試覆蓋。這樣今天新增登入方式時，測試人員可以專注驗證新的登入流程，而如果這次修改意外破壞了原本的登入流程，CI 裡的自動化測試就能把問題抓出來。

在這種環境下，團隊不需要嚴格區分手動和自動測試。找任一測試人員把新功能測完，等功能穩定之後，再把值得留下來的情境自動化，就能形成一個不錯的循環。

但問題是，不是每個團隊一開始都有這麼好的測試基礎。

如果舊有的登入方式完全沒有自動化，今天增加一種新的登入方式，就不只是測試「新的登入能不能用」，還必須擔心這次修改有沒有影響既有的所有登入方式。

這時候測試量會膨脹，除了新的登入功能驗證，還要走過舊有的登入功能。

如果團隊沒有區分手動與自動化，很容易變成大家一起下去測這個功能。原本一個人可以處理的事情，可能變成兩三個人一起測；而大家原本應該拿來建立自動化的時間，又被這些手動回歸吃掉。

接著下一個功能又來了。

而且一個產品通常一次不會只有這個新功能，同時還會有一大堆功能等著要測試、上線。每增加、修改一個功能，就可能增加一批需要人工確認的 regression scope。

最後測試量就會像滾雪球一樣越來越大。

➼ 缺乏明確的職責劃分

這時候如果沒有劃分職責，明確讓一些人負責手動、一些人負責自動，結果很容易變成：

新功能上線的手動測試永遠優先，而自動化永遠延期。

因為新功能有明確的 deadline，也是最直觀看得到的工作成果；反過來，自動化框架、E2E、CI/CD 覆蓋率都是長期投資。

嚴重 bug 當然可能造成很大的問題，但很多時候，大家都是事情真的發生之後才感受到那個「痛」。痛完、修完，過一陣子又回到原本的工作模式。

➼ 先把手動與自動化的職責切開

所以我現在覺得，對一個已經陷入測試泥沼的團隊來說，第一步不是追求「所有人都會自動化」，而是先把手動與自動化的職責切開。

讓手動測試的人員承接那些緊急、零碎、變動大的工作，確保新功能可以快速被驗證；同時把自動化的人員保護起來，專心處理舊有功能、核心流程，以及最需要被保護的業務邏輯；替自動化工作保留一塊不會被短期需求吃掉的資源。

因為如果每個 Sprint 都有新的功能要測，那麼「有空再補自動化」通常就等於「永遠不會有空」。

新功能有 deadline，但自動化可能沒有。新功能今天不測，明天就可能上不了線；但少寫一條 E2E，通常不會立刻造成任何問題。

於是只要兩者共用同一批人力，自動化就很容易在一次又一次的短期需求中被犧牲。

先把長期投資和短期需求拆開，讓自動化的人能把舊有的 regression scope 一點一點收回來，把核心流程建立成可靠的自動化測試，讓這些測試進入 CI/CD，逐漸降低每次發佈都需要人工重跑 regression 的測試量。

當這些基礎逐漸建立起來之後，情況才會開始改變。

到了這個階段，團隊才真正有餘裕考慮慢慢降低手動與自動化之間的界線，讓更多人同時參與手動測試、自動化、測試設計與測試工程。

不分手動與自動，可能是成熟團隊的結果，而不讓一個測試團隊走向成熟的起點。

成熟的團隊不是因為一開始就不分工才成熟，而是因為已經建立了足夠的測試基礎，最後才有能力不依賴這種分工。