什麼時候公司開始想找自動化測試？第一批自動化測試在幹嘛
在我的職涯裡，我常常是一間公司第一批的自動化測試。
這也讓我發現了自動化測試這個職位的有趣之處——在一間公司最欣欣向榮也最混亂的時候加入戰局。
🤖自動化測試很稀有！？
我曾經在某間公司聽到了一個很有趣的問題。
那間公司剛招募自動化測試，而我是第一個加入的。
當時有個 PM 和我聊天時問道：
「好酷喔！我到這間公司才第一次知道有自動化測試這種職缺，我以前待過的公司都沒有！自動化測試是不是很稀有啊？」
忽然被這樣問，我反而有點驚訝，我不假思索的回：
「真假？但我之前待過的公司都有自動化測試。」
講完才發覺自己根本在講幹話
我一直在做自動化測試，當然去到的每一家都有，我才會在那裡😂😂
-
上面只是個工作上有趣、輕鬆的插曲，不過從這個問題也確實讓我想到：
「沒錯，並不是所有公司都有自動化測試。」
「一間公司到了某個階段才會需要找自動化測試。」
「自動化測試很容易在一個很有趣的階段加入公司。」
因為一間公司通常不是在產品剛開始的時候，就覺得：「我們要建立一套完善的自動化測試！」
更多時候，原本大家都還相安無事⋯⋯
🌱 產品還小的時候，手動測試、大家一起測試就好
剛開始的產品，可能只有一兩個核心流程，功能還不多，業務邏輯也還很單純。
今天改了一個功能？Dev 自己測一下。
明天多了一個流程？PM 一起多測一下。
即使回歸測試純手工，但因為產品也不大，跑一次也許幾小時、半天就結束了。
很多公司在這個階段甚至根本沒有 QA。
Bug 修一修，PM 測一下、Dev 自己測一下、老闆本人點一下，產品就能上線了。
如果這時有人跳出來跟公司說：「我們應該建立自動化測試。」
大家的反應很可能是：
「蛤？」
「為什麼？」
「現在不是測得好好的嗎？」
大家說的還真的沒錯。
因為自動化測試不是只要有產品就一定要有。
自動化測試本身也需要成本。
要寫、要維護、要有測試環境、要處理 test data、要處理 flaky test。
有些功能每天介面都大翻新，你花三天把它自動化，立刻又失效；有些功能非常隔離幾乎不會被動到，你花三天把它自動化，結果之後一年只跑了兩次，或是每天跑但是單純快樂表——
那這些根本不值得自動化。
自動化不是把測試交給程式就沒事，自動化本身也是一套需要持續維護的軟體系統。
📈 直到某一天，產品開始長大了
公司開始成長。
Dev 從幾位變成十幾位，從十幾位變成幾十位。
產品從一個平台變成有 Web、App。功能越來越多。
系統之間開始串接。
原本一個簡單的登入，後面多了 OTP、第三方登入、會員系統。
原本一個下單流程，後面多了優惠券、點數、金流、退款、物流。
大家開始發現一個可怕的現象：
每次改一個地方，都不知道會不會炸到別的地方，於是 regression 的範圍開始越來越大。
以前測半天的東西，現在要測兩天。
以前一位 QA 可以負責的產品，現在開始需要兩位、三位。
開發的速度正在持續增加，release 頻率也越來越高。
然後某一天，公司終於開始意識到：
「我們是不是需要更快的驗證和測試？」
「我們是不是一直在重複測同樣的東西？」
🔥 公司開始找自動化測試的時候，通常已經開始痛了
一間公司開始認真思考要不要找自動化測試，通常不是因為 QA 團隊突然看了一篇文章：
Top 10 Reasons Why You Need Test Automation 🤖
然後隔天就熱血的決定「好！我們來轉型！」
更多時候，是因為很多事情已經開始撐不住了：
Regression 已經跑到 QA 快瘋掉。
每次 Release 都要花大量時間重複測試。
Release 越來越頻繁，但測試的時間不會增加。
核心流程需要不斷測試。
Bug 修完又導致新的 Bug。
QA 人數一直增加，但需求增加得更快。
工程團隊開始希望 CI/CD 可以跑測試。
某些 critical flow 已經不敢只靠人工確認。
Production incident 開始讓大家意識到「是不是應該早一點發現」。
這個時候，公司才會開始出現那個念頭：「我們是不是需要自動化測試？」
公司不是因為想要自動化才找自動化 QA。
公司通常是因為原本的方式開始失效，才開始找自動化 QA。
所以第一批加入公司的自動化測試，常常會面對一個非常有趣的環境。
產品正在快速成長，開發流程開始變複雜。
手動 QA 開始被大量 regression 壓垮。
系統可能開始累積技術債。
公司知道現在的做法不太行了，但還沒想清楚下一步要怎麼走。
🏗️ 所以第一批自動化測試，很多時候不只是來「寫測試」而已
當你是第一個自動化測試，進公司會遇到的基本的問題：
沒有測試框架，來建測試框架。
大家不知道什麼該自動化或是每個東西都想自動化，來決定自動化的優先順序。
怎麼整合到目前的 CI/CD 流程裡，目前的流程是不是能插入一些不同層級的測試進去。
這些問題背後有時藏了更深層的問題：
建測試框架、寫 case 都簡單，但我們有測試環境嗎？（對，我看過沒有的）
我們有測試環境，但測試環境穩定嗎？
測試環境本身和測試資料能足夠模擬真實環境的狀況嗎？
目前到底痛在哪裡？自動化要解決的是 regression 工作量？release 速度？還是其他？
測試究竟要怎麼融入現在的開發流程？
甚至還有，有些功能，根本沒有人知道「正確的行為」該是什麼。
自動化測試像是一面照妖鏡。
自動化直接開寫可能會遇到了各種 flaky test，這些 flaky 可能原本在手動測試裡就存在，只是被 QA 的經驗和判斷暫時吸收掉了。
QA 這次點失敗了，可以自己 retry 一次、環境暫時500就等一會再測、資料不對，就自己去後台修改一下、規格不清楚，就去問 PM⋯⋯
很多問題都是靠著人類的經驗和彈性處理掉的。
當你想把這件事交給機器每天自動執行時，事情就沒那麼簡單了，我們必須把很多原本模糊的東西事先定義清楚、準備好：
要建立隔離的測試環境？先進行 smoke test，通過才開始進行正式測試？未通過就先等待多久再嘗試？或是應該有監測，當某些health check 失敗就警示？
測試這些東西需要什麼樣的 test data？足夠貼進真實環境嗎？會被大家更動的話，我能夠在測試前通過 api 或 DB 修改嗎？
依賴第三方服務的部分，我能夠 mock 第三方服務的結果嗎？
我們是不是要定義核心的 case，是不是要加入failure retry？在 CI 上哪些東西失敗應該阻擋 deploy？
當這些問題開始被攤開來討論時，第一批自動化測試所做的事情，不只是寫自動化測試，而是先需要在公司建立一種開發流程和測試流程的 mindset。
讓測試從上線前 QA 去點一點，轉變成我們要怎麼設計出可以持續驗證產品還是正常的系統。
TL;DR
自動化測試稀有嗎？我體感當然不稀有，不過的確在一間公司到了在某個階段，才會開始需要。
第一批自動化測會在一間正在高速成長的公司裡，開始回答一個更根本的問題：我們到底要怎麼持續確認，這個越來越複雜的產品還是正常的？有時侯這需要在公司裡建立一套開發流程和測試流程的 mindset。
留言
張貼留言