給不小心就會焦慮的 QA：從自動化轉回手動測試後，我怎麼跟 AI 當夥伴

給不小心就會焦慮的 QA：從自動化轉回手動測試後，我怎麼跟 AI 當夥伴 主管跟我說，接下來先回去做手動測試。 我第一個反應是驚訝，第二個反應是算帳：我是不是沒價值了？會不會被降薪？那幾年寫的自動化框架，是不是就這樣白費了？ 後來才知道，原因很普通：當時沒有自動化的需求，專案資源也有限。聽完稍微釋懷，但心裡還是有點擔心。 衝擊和不安，是兩種不同的焦慮 衝擊 是已經發生的事。職務被調整，這件事已經定了，再怎麼想也不會變回去。 不安 是還沒發生的事。AI 會不會讓 QA 變少？我學的東西會不會過時？這些問題沒有答案，所以腦袋會一直轉。 分開之後比較好處理。衝擊能做的只有接受，然後問自己「現在手上有什麼」。不安則要靠行動去縮小，光想是想不完的。 我後來給當年那個自己的一句話是： 自動化測試是養分，不會在你身上消失。 寫框架時練出來的東西，像是把問題拆小、想清楚架構、看得懂程式和資料流，到了手動測試和 AI 工具上，一樣用得到。 窮忙濾鏡：什麼都想學，結果什麼都沒開始 焦慮的時候，我會不自覺戴上一副濾鏡：看到新工具就覺得「我應該學」，看到別人分享 AI 工作流就覺得「我落後了」。 這就是窮忙。很忙，但忙的是「害怕來不及」，不是解決眼前的問題。 AI 圈的更新速度會把這副濾鏡放大。今天是新模型，明天是新的 Agent 框架，後天又有人說 prompt engineering 已經過時。每一個都追，就會一直處在「還沒學完」的狀態。 摘掉濾鏡的方法，對我來說只有一個： 挑一件每天重複、又讓你煩的測試工作，只處理那一件。 從一個讓我煩的錄影流程開始 我挑的是手機測試錄影。 回報 bug 要附影片，可是手機錄影的步驟很瑣碎：開錄、操作、停止、找檔案、傳到電腦、再想辦法分享給工程師。影片還常常存在手機裡找不到，或檔案太大傳不出去。 這件事不難，就是煩，而且每天都在發生。很適合拿來當第一塊積木。 我用 AI 做了兩件事。第一是加速開發。第二是驗證想法可不可行，很多點子以前會停在「應該可以吧」，現在可以先做出來試，不行就換。 這個工具目前的完成度和實際省下多少時間，我還沒有正式量過，所以這篇不寫數字。 開始行動之後，反而更不安？ AI 產出很快，測試案例一下子就列滿，Log 丟進去馬上有分析。速度變快了，我卻更不安：這些東西對嗎？ 這份不安其實是對的。我的看法是： 人力不會變，瓶頸在驗證。 AI 讓產出變便宜，但判斷對錯這件事沒有變便宜，還是需要人審。 Stack Overflow 2025 年的開發者調查裡，八成以上的開發者在用或打算用 AI 工具，但不信任 AI 輸出準確度的人（46%）比信任的人（33%）還多。大家都在用，但多數人並不放心。 所以 AI 產出讓我不安的時候，我就知道該停下來驗證了。 調整節奏：把工作拆成積木 我的做法是把測試工作拆成幾塊積木，每塊都可以單獨用 AI 改善： | 積木 | AI 做什麼 | 我做什麼 | | | | | | 需求提問 | 從不同角度提出疑問，給多種思路 | 挑出真正重要的問題去問 PO | | 展列案例 | 展開情境 | 檢查風險和適用性，刪掉不合理的 | | 手機錄影 | 降低錄影、保存、分享的摩擦 | 決定要錄什麼、給誰看 | | Log 分析 | 像旁邊坐了一個 DBA 和資深工程師，解釋程式、流程和資料邏輯 | 拿證據驗證它的解釋 | | 優先級判斷 | 分析需求複雜度 | 依專案風險調整權重 | | 知識庫 | 讀取累積的案例和 Bug | 持續更新、刪掉過時資料 | 六塊不用全做，每次只動一塊。哪一塊最痛就先換哪一塊，其他照舊。 AI 提供分析，用參數校調、做決定的是 QA，所以右邊那欄我不交出去。 分辨「應該做」和「想要做」 窮忙濾鏡最常講的話是「應該」：應該學這個框架、應該做一個 Agent、應該跟上那個趨勢。 「應該」會讓焦慮變成習慣。因為「應該做的事」永遠做不完，而且標準是別人訂的。 我後來改問自己：「我想解決什麼問題？」 我想要 AI 給出來的測試觀點像我，不像一份通用清單。所以我開始建立測試案例和 Bug 的知識庫，把自己怎麼看風險、怎麼拆需求放進去。這件事沒人規定我做，但工具大家都買得到，測試觀點只有自己有。 用自己的眼光看事情，還有一個附帶好處：比較不會被旁人的進度綁架。別人展示的華麗工作流，背後是對方的產品和對方的痛點，不一定是你的。 行動和目標有沒有一致 假設測試案例產出變快了，可是正式環境的 Bug 沒有減少，那代表什麼？我的判斷是 root cause 還沒找到。以我的情況來說，第一個要回頭調的是複雜度分析：AI 評估哪裡風險高的依據，可能跟產品實際出問題的地方對不上。 光看 Bug 數量下不了定論，這只是診斷方向。但它會逼你確認「我在忙的事，跟我要的結果有沒有關係」。 DORA 2024 年的報告估計，AI 採用率每提高 25%，交付穩定度約下降 7.2%。寫得快，不代表出得穩。 凡事盡力就好，高標準不是好事 知識庫、跨專案框架、風險報告，我都想要，但不會一次做完。 現在比較實際的做法是： 先從測試案例和歷史 Bug 開始累積，不追求完整。 框架設計成可以複製，換專案時再補那個專案的 Domain Knowledge。 允許不同產品、不同測試工程師有各自的風險權重，不強求統一。 知識庫要持續優化和反覆驗證。AI 回答不理想時，我先檢查知識庫有沒有過時、需求寫得清不清楚。 跨專案框架和風險報告這兩塊，對我來說還在規劃。 給一樣容易焦慮的你 如果你也在擔心 AI，或還沒真的碰過它： 先玩玩看。挑一件每天重複的測試工作，試著讓 AI 幫忙。一點一點研究，不求多。 要變，但不用否定過去的自己。你寫過的自動化、踩過的坑、對產品的理解，都會跟著你。接下來的 QA，我覺得會越來越像風險評估專家：AI 提供分析，我們用專業校調，最後交出一份讓 PO、工程師和主管看得懂的品質報告。 我給自己的標準只有一句：只要發揮價值。 參考資料 Stack Overflow Developer Survey 2025 — AI — 開發者使用 AI 工具的比例，以及對 AI 輸出準確度的信任程度 DORA 2024 Accelerate State of DevOps Report — AI 採用率與軟體交付穩定度的關係 Google Cloud Blog: Announcing the 2024 DORA report — DORA 2024 重點摘要，包含 AI 對交付表現的影響