「剛轉做自動化 QA 時，我以為自己拿到了神兵利器；直到每天被 CI 紅燈追著跑，我才發現自動化救不了混沌的品質。」

嗨，我是 Jane。

作為一名資歷十年的自動化 QA 測試工程師，我的日常其實跟大家想像的不太一樣：很多人以為我們每天就是優雅地寫寫腳本、按下 Execute，然後看著測試報告全綠過關。

但真實的情況往往是：

• 早上進公司，先看到 CI 跑出 5 個紅燈，排查了半天發現 4 個是測試環境不穩定、1 個是 DOM 變了但 Dev 沒通知。
• PM 跑來問：「Jane，我們不是有寫自動化嗎？為什麼昨天 Release 上線還是爆出 Bug？」
• Dev 覺得：「測試腳本壞了？那是 QA 的程式碼有問題，不關我的事。」

如果你也是寫了 1~5 年自動化測試的 QA，這些場景你一定不陌生。我們常夾在主管的期待、開發團隊的推託與不穩定的測試腳本之間。今天這篇文章，我想以第一線自動化 QA 的視角，聊聊我們與團隊最容易落入的 5 個「錯誤期待」。

期待一：「只要寫了自動化，我就不用再做手動測試了！」

💥 第一線 QA 的現實體會

當我剛把第一套 UI 自動化腳本跑通時，心裡確實爽快：終於不用再重複點擊那幾十個輸入框了！

但很快現實就打臉了。自動化腳本非常「死板」，它只會按照你寫好的 assert 去檢查。有一次我們的自動化測試全過（綠燈），但我手動點開網頁一看，頁面上的按扭竟然跑版到遮住了文字、圖片整個掉圖。

💡 我們的調整

• 自動化是用來「驗證（Verification）」，不是用來「感知（Perception）」。
• 自動化幫我們扛下了最無聊、最重複的 Smoke Test 與基本流轉，把我們省下來的時間，拿去做更需要人類直覺與邏輯的「探索式測試（Exploratory Testing）」。手動測試沒有消失，只是變得更有價值。

期待二：「自動化測試應該要把產品所有的 Bug 都抓出來！」

💥 第一線 QA 的現實體會

當上線爆出 Bug 時，最怕聽到的就是：「這條路徑自動化沒跑嗎？怎麼沒抓到？」

但大家常搞錯一件事：自動化腳本只會抓到『你預先教它要檢查』的 Bug。如果這個 Bug 是來自全新的商業情境、或是極端網路延遲下的 Race Condition，原本的腳本根本不會涵蓋到。

💡 我們的調整

• 自動化的核心價值是「防守（Regression Control）」——確保今天改的 Code 沒有把昨天好端端的功能改壞，而不是去「進攻」發現全新的漏洞。
• 不要期待腳本能幫你抓到未知的 Bug，它是我們的防禦裝備，不是偵測掃描器。

期待三：「測試案例寫越多越好，覆蓋率要衝到 100%！」

💥 第一線 QA 的現實體會

曾經我也為了追求 KPI，一個月猛寫了上百條 UI 測試案例。結果呢？我掉進了自己挖的維護地獄（Maintenance Hell）。

前端只要改個 Class 名稱或 CSS 結構，我當天就要花 3 個小時去修 50 條壞掉的腳本；環境網路一慢，腳本就跳 Timeout。那段時間我根本沒有時間寫新的測試，每天光是修舊腳本就飽了。

💡 我們的調整

• 質遠比量重要。10 條穩定、每次失敗都代表產品真有 Bug 的高品質腳本，價值遠高於 100 條天天 Flaky（忽真忽假）的脆弱腳本。
• 學會說「不」：不要什麼都往 UI 自動化塞，能寫 API 測試的就不要寫 UI，能交給 Dev 寫 Unit Test 的就別重複寫。

期待四：「CI 通過率 100% 就代表產品品質無懈可擊！」

💥 第一線 QA 的現實體會

為了讓 CI 報告看起來漂漂亮亮（全綠），我曾看過有些專案做了很危險的事：

• 把常常失敗的測試案例打上記號跳過（Skip）。
• 加了 try-catch 把 Error 吃掉，或是只驗 HTTP Status Code 200，不驗 Body 的資料對不對。
• 設定 retry: 3（自動重試），反正跑三次只要過一次就算綠燈。

這樣的「100% 通過率」只是一種自我麻痺的假象。

💡 我們的調整

• 身為自動化 QA，我們要守住對「失敗」的敏感度。每次失敗都是訊號，不是雜訊。
• 寧可要一個真實反映問題的 90% 通過率，也不要一個被過度寬容掩蓋問題的假 100%。

期待五：「自動化測試是 QA 部門自己的事，Dev 不用管」

💥 第一線 QA 的現實體會

這是我覺得最孤單的時刻：QA 在後面苦苦追趕、寫腳本，Dev 在前面狂產 Feature。當 QA 喊著「頁面沒有 data-testid 抓不到元素」時，Dev 覺得這不關他的事。

最後產出的自動化架構極度脆弱，因為產品程式碼本身根本沒有考慮過「可測試性（Testability）」。

💡 我們的調整

• 品質是全團隊的責任（Whole Team Ownership）。
• 自動化 QA 的角色不只是「寫測試的人」，我們更應該是「推動可測試性架構的橋樑」。我們需要跟 Dev 溝通：如何在前端加入統一的測試定位器、如何提供測試用的 Mock API 或測試資料，讓測試程式碼成為產品開發的一環。

自動化 QA 的心境轉變：從「寫腳本機器人」到「品質推進者」

從剛入行時盲目追求「案例數量」與「工具語法」，到現在我越來越清楚：自動化測試只是一個工具，真正的關鍵在於『測試策略』與『團隊溝通』。

搞清楚哪些不該寫、讓團隊知道自動化的邊界在哪裡，我們才能擺脫天天消防員式修腳本的輪迴，建立出一套自己敢信任、團隊也願意採納的自動化測試體系。

明日預告

告別了這些美麗的幻想後，下一個我們在團隊裡最常被問到的硬核問題就是：
「Jane，你花了兩個月做這套自動化，到底幫我們省了多少時間？價值在哪裡？」

明天 Day 5，我們就從第一線 QA 的角度來聊聊：《 Day 5｜如何衡量自動化測試的價值：從指標到團隊信任 》。