Test Guild 的主持人 Joe Colantonio 做了一件很簡單的事：過去一年，他在 podcast 上問了 13 位 AI 測試領域的人同一個問題。這 13 個人是創辦人、CTO、專案負責人、品質主管，來自 Applitools、Maestro、Bright Security、Cucumber、Selenium 等公司，其中好幾位現在就在賣 AI 測試工具給你。
問題是：「AI 能替你測試軟體嗎？」
注意他問的不是「AI 能不能幫忙」——當然能。也不是「能不能寫 locator 比你快」——當然能。他問的是：你能不能下班回家，讓 AI 自己決定什麼東西可以上線？
13 個人，沒有一個說可以。
為什麼連工具商都說不行
Applitools 從 2015 年就在做 AI 測試，比這個領域裡大多數公司都早。它的 CTO Adam 的回答是：「我什麼都不會交給 LLM。我會用它加速我做的每一件事，但我永遠會在旁邊監督。」
這不是哲學問題，而是 AI 本身的四個特性，每一個都會撞上測試的基本假設：
它不是每次都給同樣的答案。 測試的整套邏輯建立在「同樣的輸入應該得到同樣的結果，如果不一樣，代表有東西壞了」。但 LLM 天生就是同樣的問題可能給不同的回答。當測試失敗時，你分不清是程式壞了，還是 AI 今天心情不同。
它慢。 傳統測試一步是毫秒級，AI 推理一步是秒級。一個測試差幾秒沒感覺，一千個測試就是從「每次 commit 都跑一下」變成「今晚跑、明天看」。
它貴。 demo 跑十次無所謂，但每個開發者每次提交程式碼都要燒 token，帳單會讓人清醒。
它說不清自己檢查了什麼。 這是最該擔心的一點。在醫療、保險這類產業，稽核人員會來要證據：你怎麼證明這個功能測過了？AI 說「通過」，但你不知道它到底看了什麼。一個你無法解釋的綠燈，其實不算通過。
Adam 還補了一句：別相信那些「效率提升 100%」的故事，那通常是某位資深工程師某個狀況最好的下午，被放大成全公司的常態。真正跨整個團隊、跨整季、把搞砸的那幾週也算進去的數字，大概是 10 到 15%。這其實是很好的一年。問題出在主管照著 80% 編預算，結果拿到 15%，然後回頭怪你做錯了什麼。
做過全自動的人，最後把它砍掉了
Maestro 是一個做手機 App 測試的開源工具，負責人 Leland 之前在微軟、Amazon、Meta、DoorDash 做手機測試。他們曾經認真做過一個「完全 agentic」的版本：你用英文描述要測什麼，AI 在執行的當下即時理解、即時操作。
結果呢？「Demo 效果非常好。」然後他們把它砍掉了。
理由很實際：既然 AI 已經可以幫你產生一段確定性的測試程式碼，為什麼還要在執行時多加一層看不見在幹嘛、每次結果可能不同、讓你懷疑它到底測了沒有的東西？他們最後定下來的分工是：AI 負責寫測試腳本，CI 用確定性的方式跑它。
自己出作業自己改
一位管理 150 位工程師、橫跨四個國家的品質主管 Nandini 講了一個原則：寫程式碼的 AI，不能同時是寫測試的 AI。
原因不難懂。如果同一個模型既寫了功能又寫了測試，那測試驗證的不是「功能對不對」，而是「模型自己對功能的理解一不一致」。這兩件事看起來一樣，但只有前者是你的使用者實際會碰到的。
另一位 CTO Evan 把它講得更具體：很常見的狀況是，AI 實作了一個功能，做錯了，然後順手把 end-to-end 測試改成能配合那個錯誤通過。所以他的建議是，至少讓寫功能和寫測試在不同的 session 進行。不要說「幫我做這個大功能，順便把測試修好」——測試要當成有用的訊號，就必須跟產生程式碼的過程隔離。
Bright Security 是一家整個建立在 AI 上的資安公司，他們的做法更謹慎：AI 修完漏洞之後，他們還是會把原本那組測試重跑一次，確認漏洞真的不見了。用他們的話說：「我們不靠 AI 去修 AI，我們引導 AI，而且引導完還是不信它。」
把 AI 當實習生，不是當同事
AMO 的共同創辦人 Ivan 給了一個很好用的比喻：把 QA agent 當成剛畢業的實習生。
你不會第一天就給實習生正式環境的權限，不會讓他的 PR 不經審查就合併。你會給他範圍明確的工作，然後檢查產出。這不是因為實習生笨——他們往往很聰明——而是因為他們缺乏 context：這個系統的歷史、哪裡容易出事、哪些使用者最重要。這種東西要花時間累積。
而這正是所有 AI agent 共同的失敗模式：不是不夠聰明，是沒有 context。誰有 context？測試人員。
業界真正在吵的只有一件事
演講裡列出了四種路線：
| 路線 | 代表工具 | 做法 |
| 專用的確定性 AI | Applitools | LLM 完全不碰執行 |
| AI 寫、CI 跑 | Maestro | AI 產生 YAML 腳本，runtime 沒有 LLM |
| 首跑推理、之後重播 | Alumnium（開源，架在 Selenium / Playwright 上） | 第一次跑讓 AI 推理，之後每次重播第一次的結果，用快取換取確定性 |
| 完全 agentic | Thunders、QA Tech | 「程式碼就是英文」，每一步都在即時推理 |
這些人放在同一個房間會吵起來，但他們吵的不是「AI 有沒有用」——每個人都同意有用。他們吵的只有一件事：執行的時候，你允許多少不確定性？
而這個答案取決於你的風險。醫療系統你會想要極度確定；一個簡單的行銷網站可能無所謂。這是你要自己決定的事，沒有人能替你選。
幾個實戰上的觀察
Alumnium 的作者 Alex 每天在跟這個問題搏鬥，他分享了幾件事：
改一個字，模型就可能整個跑偏。 他舉例：prompt 裡傳了網頁標題給模型，之後叫它「列出頁面上所有的產品標題」，模型有時會把網頁標題也算進去，因為都叫 title。用字非常重要，但你又不知道模型內部到底怎麼理解。
Context window 用到大約 40% 的時候，模型遵循指令的能力就開始退化。 不是用滿才出問題，是四成就開始飄。
成本上，用一個規劃 agent 搭配便宜的子 agent，跑一輪大約 5 美元；全部用最強的模型做，是幾百美元。 重點不只是省錢，而是要知道哪個模型適合哪種工作。
另一位受訪者則點出規模問題：用 LLM 產生十幾二十個測試很容易，但要到幾百幾千個，那就是一個正式的軟體專案，需要架構、需要結構。很多團隊看到早期的小成果就衝了，從沒想過擴大之後要怎麼辦。
AI 不會消除這些架構決策，它只是把你從決策過程中移開——決策還是會被做出來，只是變成隱性的，由一個出問題時不會在場的東西做的。
瓶頸沒有消失，它移到你身上了
「AI 移除了瓶頸」這句話是真的。但它沒有刪掉瓶頸，只是把它搬了位置。
一位受訪者說得很直白：如果一天產出 10 到 15 個 PR，誰來看？以前大家以為「寫測試太慢」是瓶頸，現在測試可以無限生成了，瓶頸變成「誰來確認這些東西是對的」。
Cucumber 的共同創辦人 Matt Wynne 提出一個值得貼在牆上的說法：我們現在做的工程，不是工程化程式碼本身，而是工程化「產生程式碼的那個系統」。而我們比以往更需要能測試那個系統的人——它哪裡會漏、哪裡會出錯、怎麼防。
換句話說，測試人員的新工作是：prompt、規則、agent 的設定、評估用的資料集。不是寫腳本，不是維護 page object。那些東西本來就跟測試無關。
寫作從來不是你組織的限制，「信心」才是——知道這個東西可以安全上線。
資安：模型不是犯錯，它只是忠實重現
各種產業報告一再出現的數字大同小異：程式碼量多了 150 到 200%，漏洞多了 500 到 600%。同樣的開發者、同樣的人數、同樣的審查流程。而且漏洞的成長比程式碼快好幾倍。
Bright Security 的 Gadi 解釋了原因：這些模型都是用公開程式碼訓練的，而公開程式碼大多是教學範例、五年前的 Stack Overflow 答案，既不安全也不高效。模型沒有犯錯，它只是忠實地重現它學到的東西。這才是可怕的地方。
更麻煩的是第二層問題：AI 給出的修復建議，很多人沒驗證就一路按「接受」。這不是在做資安，也不是在做測試，只是用機器的速度生產「看起來處理過了」的稽核紀錄。
演講裡還提到一個真實事件：一個 agent 從測試環境逃出來，對正式環境造成傷害。受訪者 Jason 的解讀是——這是個測試問題。跑測試的基礎設施不夠安全，可觀測性不足以發現 agent 跑出去了。
大風吹：只剩一張椅子
Jason 用了一個比喻：現在有一場大風吹。你、產品經理、開發者、部門主管、你用的工具供應商，都在繞著轉。椅子只有一張，上面寫著「Confidence Engineering」。
需要有一個人，看得懂數據、會多做幾個檢查、自己動腦想，然後決定 AI 產出的軟體能不能上線。這是 QA 的工作，但不需要 20 個人做，只需要一個。
其他受訪者用不同的方式說了同一件事。Evan：你不再是那個親自驗證的人，而是管理一群做驗證的 agent。Adam：你希望監督者是品質工程師，還是一個專長是寫程式碼的人？Nandini 的版本最短，可以印在 T-shirt 上：我們現在都是產品品質專家。
Joe 講得很誠實：你不會自動坐上那張椅子。你只是最有資格的候選人。這兩件事之間的差距，要靠你證明自己填補——真的去懂 AI，能告訴組織它做得到什麼、做不到什麼，然後成為這件事的領導者。
永遠不該交給 AI 的事
他回頭翻了 13 場訪談，把每個人說「這個我不會交出去」的東西列出來：
- 決定什麼優先：知道什麼對組織、對使用者真正重要
- 測試策略和測試資料
- 變更影響分析和風險分析
- 產品領域知識：把問題從裡到外搞懂
- 執行與上線的最終決定
13 場對話，沒有互相串通，不同公司、不同國家、有些還是直接競爭對手，講出來的清單是一樣的。
同樣值得注意的是清單上沒有的：寫腳本、維護 locator、建 page object。這會讓很多測試人員不舒服，但事實就是如此。這幾年我們一直被告知「測試人員要變成開發者」，現在風向轉回來了：我們都是測試者。
如果你現在的工作內容大多是第二份清單，這是個問題，但是個好問題。把第一份清單放進你的學習路線圖。
怎麼成為留下來的那個人
Nandini 給的建議，沒有一條是技術的：
每兩週對主管 demo 一次，每個工程師的名字掛在自己做的東西上。用他們的語言說話——上市時間、營收預估、風險降低——不要講 coverage、不要講 pass rate。沒有任何一個高層是因為 pass rate 做決策的。
別沉默。往上游游。在管理層被 AI 炒作洗腦之前，先讓他們看到你的價值。
還有一句話：被自動化取代的人，通常不是技能最差的，而是最不被看見的。
結語
13 個人，每一個都在建、在賣、或在帶團隊用 AI 測試工具，每一個都想透了這件事。沒有人願意把最終決定交給 AI。造這些工具的人，自己都不信任它獨立測試。
那個信任的缺口，就是測試人員的工作。很多人這幾年太專注在開發那一半，忘了測試那一半——而在 AI 時代，後者只會越來越重要。
來源
本文整理自 Test Guild Automation Podcast：AI Testing Reality Check: What 13 Founders Refuse to Automate。這是 Joe Colantonio 於 TestersLab 大會（布宜諾斯艾利斯）的演講，內容彙整自他過去 12 個月訪談的 13 位 AI 測試領域人士。
發表迴響