Slack 用 AI Agent 強化 E2E 測試
Slack 提出的 agentic testing，是把 E2E 測試從「照腳本逐步點擊」改成「給 AI agent 一個任務目標」。Agent 會觀察當下 UI 或 API 狀態、規劃下一步並動態調整路徑，再以工程師預先定義的 assertion 驗證結果。按鈕搬家、DOM 結構微調時，它不會立刻判定失敗，而是嘗試其他操作方式，主要用來降低介面快速改版造成的假警報與維護成本。
現實應用
這套方法適合介面更新頻繁、跨服務流程複雜的大型產品，例如註冊、權限設定、訊息傳送或付款等完整使用者旅程。QA、前端團隊與平台工程師可以拿它探索難以窮舉的操作路徑、除錯 flaky test，或重現正式環境才出現的問題。它尤其適合「功能其實正常，但 selector 或畫面結構變了」的情況；核心商業邏輯與 API contract 仍應交給 deterministic tests。
期望評估
我認為低標期望，是減少一部分因 UI 小改動造成的 E2E 測試失敗，並透過 execution trace 看清楚 Agent 做了哪些判斷，讓除錯不再只剩一張失敗截圖。
我猜高標期望，是把過去需要人工操作半小時才能重現的複雜流程，轉成可重跑、可檢查的目標描述，進一步成為探索測試與 production issue reproduction 的常用工具。不過它短期內不會取代測試金字塔，也不適合讓 Agent 自由探索所有正式資料與高風險操作。
商業策略分析
受影響最大的是傳統 UI 測試平台與大量依賴錄製腳本的工具商：只強調自動產生 selector，差異會愈來愈小；真正有價值的會是 Agent 行為限制、可觀測性、重播能力，以及與 CI、測試資料和權限系統的整合。
我認為值得跟進，但應先放在高維護成本的少數流程，而不是全面改寫測試。Slack 也明確把它定位成既有測試的補充；目前 Agent 執行成本較高，更適合針對性除錯與探索測試，而非每次 commit 都跑。企業採用時還得處理操作邊界、停止條件與資料安全，否則測試彈性會變成不可控風險。
實作細節
典型流程是輸入 test intent，由 Agent 規劃、執行、觀察並反覆調整，直到完成目標或觸發停止條件，最後再跑 assertion。系統需限制允許的動作與探索範圍，並保存完整決策及互動紀錄，方便重播失敗。已知限制是成本與非確定性，因此關鍵 regression、單元測試、整合測試及 contract 驗證仍要保留固定腳本。