前言 昨天是被動讀已經留下的證據，東西都在檔案裡，差別只在開哪一份。今天換一種姿勢：挑一個 UI 動作，主動追它到底做了什麼，然後面對昨天四種來源全部乾淨、卻確實有缺陷的那種情況。底下的數字都是 2026-08-02 實跑量到的，證據在 output/evidence/20260802-withbugs-network/，對照組在 output/evidence/20260802-toolshop-checkout/。 為什麼要追到 network UI 是最會騙人的一層。畫面上的每一個數字、每一個狀態，都可以是前端自己畫的。徽章從 0 變 1，可能是因為後端建了購物車，也可能只是前端把一個變數加一。這兩件事在畫面上長得一模一樣。 不追到 network，你驗的就是前端的渲染邏輯，不是產品的行為。而昨天那四種來源有個共同的盲點：它們都只回答「發生了什麼」，不回答「
前言 Day 8 教會它留證，一輪跑完會交回截圖、console、network、trace 四份檔案。今天面對下一個問題：四份檔案攤在面前，你怎麼知道該看哪一份？底下的數字都是 2026-08-02 對 automationexercise.com 實跑量到的，證據在 output/evidence/20260802-automationexercise/。 為什麼要分辨證據來源 留證有個陷阱：檔案愈多，愈像做完了。實際上那四份檔案回答的是四個不同的問題，而它們之間有縫。 截圖說得出症狀，說不出原因。network 說得出發了哪些請求，說不出回 200 的那一筆內容是錯的。console 說得出程式報了什麼錯，說不出畫面因此長成什麼樣。 縫的代價是漏。缺陷同時落在兩份檔案上，一份寫症狀、一份寫原因，只讀其中一份的人會判它通過。更糟的是這種漏不會留下痕跡：你手上有完整的證據包，報告寫「未發現異常」
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 第一週結束時它已經能操作產品，也留得下東西，只是留得很粗糙：截圖是隨手截的、console 是整包倒出來的，哪些重要、哪些是雜訊分不出來。今天把「有留」變成「留得對」，主角是 evidence-package 這個 skill，底下靠 Playwright 的 screenshot、trace、network 產出硬證據。段落順序照 2026-08-02 拍板的節次走，數字都是那天實跑量到的。 為什麼第一件事是留證 現在還沒開始找 bug，先教蒐證看起來像繞路。反過來想：等到真的找到東西才學留證，那一刻你手上只有一句「我剛剛看到它壞掉」，重現要重跑、細節靠回憶、開單前還得再走一次。這是新手最常付的一種學費。 留證還會逼出誠實。一份證據包會逼出兩件事：你只能寫得出檔案接得住的結論，而且你必須把看到的跟推論的分開寫。趁還沒有「我找到大 bug
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 新同事到職的第一週，我通常不會急著請他找產品的問題，而是先讓他把流程完整走過一次。跑完之後，再請他說說看：他做了哪些操作、畫面上看到了什麼，又在哪些地方停下來確認。 原因很簡單。如果連產品正常運作的樣子都還說不清楚，這時候提出的「異常」多半也很難判斷。 所以今天先讓這位 AI 同事做第一件實際工作：自己走完一條產品流程。 為什麼第一項任務不急著找 bug 我想先確認三件事。 第一，前六天準備的環境到底能不能用。瀏覽器、測試帳號、產品知識和權限都已經設定好了，但這些東西只有真正跑過一次，才知道有沒有接好。如果現在失敗，反而容易處理，因為問題大多還在環境或設定，不必立刻懷疑產品。 第二，它是否真的讀得懂畫面。瀏覽器能把頁面內容交給它，不代表它知道哪個是主要按鈕、購物車在哪裡，或目前走到結帳的哪一步。這些能力不能靠設定檔確認，只能看它實際操作。 第三，從第一趟任務開始就要求它留證據。這個習慣越早建立越好。若等到它開始回報問題，才發現截圖、console 或 network 紀錄都不完整，最後還是得自己重跑一次確認，
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 新同事報到，IT 開的是他自己的帳號，不是把你的密碼抄一份給他。能開哪些系統看職務，不是一次全開。 這件事我們都覺得理所當然。但很多人讓 AI 上工的時候，是直接把密碼貼進對話框的。 今天要處理的就是這件事。而且「權限」在這裡不是一件事：前四件是一般 coding agent 也有的本機與工具控制，第五件是任務授權，最外面還有受測系統本身的強制控制。 為什麼 SDET 的權限題比一般 agent 大一圈 一般 coding agent 的副作用是改你的碼。它改壞了，git checkout 就回來了，最糟糕的是浪費了你半小時。 這位同事的副作用打到別人身上： * 開一張 issue，會通知一整個 channel 的人 * 重置共享測試環境，會擋掉別人正在跑的 pipeline * 刪測試資料，可能毀掉同事跑到一半的驗證 * 對正式站做安全測試，那是另一種等級的麻煩 這些動作的共同點是收不回來。
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 昨天發了員工手冊，這位同事知道公司的規矩了。但它還不知道自己要測的東西長什麼樣。 先別急著餵文件。這一集要回答的是更前面的問題：它到底在哪些時候需要產品知識？ 這個問題的答案決定了你要準備多少東西。準備太少，它判不出真正的問題；準備太多，你會花兩個禮拜整理一份沒人看的文件。 為什麼不是先整理一份完整的產品文件 新人訓練最直覺的做法，是把手上所有文件丟給他：需求、規格、API 文件、歷史決策。對真人來說，這頂多是浪費幾天，對這位同事來說，並不需要這麼做。 所以問題要倒過來問：它在哪些時候真的需要規格？答案不是「隨時」。有一整類缺陷，它光看畫面就判得出來，那類完全不用你準備；剩下那類，不管你讀幾遍，畫面都判不出來，那類才值得你寫。 先看第一類長什麼樣，再看它的天花板在哪裡。 有一種 bug，不需要任何產品知識 先看一個真的抓到的例子。 我讓它去逛一個電商 demo 站的購物車，它回報了這個： 購物車頁面每一列商品的 Total 欄位一律顯示 $00.00，
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 「下禮拜有個新功能要上線，要麻煩你幫忙看一下有沒有問題？」 收到這個任務之後，你的同事通常會先問一串問題，畢竟同事不會通靈，如果通靈可以的話，是不是觀落陰要變成每個測試人員的技能： * 功能相關的文件放在哪裡？ * 有沒有開發相關文件或測試計畫？ * 已經有手動測試案例了嗎？ * 目前有沒有自動化測試？ * 迴歸測試有包含這個功能嗎？ * 測試完之後，測試報告要放在哪裡？ 我的這位新同事也是一樣，如果每次開始工作前都要重新講一次專案結構、測試流程和相關操作限制，我會把時間全部花在重複交接上，不如我把這些工作須知，都寫進 CLAUDE.md 裡面。 它就是發給新同事的員工手冊：不會包含所有知識，但會告訴他開始工作前該知道什麼，以及需要更多資訊的時候該去哪裡找。 CLAUDE.md 是什麼 一份給 Claude Code 的專案指示，專案層級通常放這兩個位置之一： ./CLAUDE.md ./.claude/CLAUDE.md 每次新對話開始的時候，Claude Code 會把範圍內的 CLAUDE.md 載入自己的腦袋。除了專案底下這份，它也支援使用
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 昨天說到脫穎而出的是 Claude，今天先講為什麼。 Claude Code 有一套叫 skill 的機制：你可以把一段工作方法寫成 Markdown 檔，放進固定位置，之後它遇到對應的情境就會自己讀進來照做。這件事聽起來平凡，但它把兩樣東西分開了 —— 怎麼做是能力，做什麼是產品知識。能力寫成 skill，可以帶著走；產品知識放在另一個資料夾，換一個受測產品就換一份。 這正好是我這 30 天想建立的東西：這是一位換了公司甚至模型也還能繼續工作的同事，而並不需要綁死在某個專案裡的提示詞，當然針對公司產品還是要調整一番，但隨著模型越來越厲害，我相信這件事情會越來越容易。 好，先回到今天要做的事，就是幫這位同事準備辦公環境：一台電腦、一雙能看見畫面的眼睛、一本記事本，還有報到手續。 Claude Code 的工作方式 Claude 是 Anthropic 開發的 AI 模型，能理解人類語言、分析內容、產生程式碼，
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 徵人啟事發出去之後，我收到不少應徵信。Gemini、ChatGPT、Claude 都投了，還有幾個開源模型，包括七月剛放出權重的 Kimi K3。每篇自我介紹都很精彩：有的說自己擅長剪片配音，有的說最會搜資料，能把一堆雜訊整理成學習報告跟投影片，有的自稱全能翻譯，任何語言即時轉換。但沒有一個講得出 Agentic SDET 要做什麼，於是我寫了這篇文章。 Agentic 之亂 我想起多年前的 Ops 之亂。當時的情況跟現在的 AI 差不多，大家喜歡在職稱前面加個字首：DevOps、TestOps、SecOps，接著是 DevTestOps，甚至 OpsOps。這樣說來，我把 Agentic 湊到 SDET 前面，應該也不為過。 但這個字首背後有實質差異。傳統測試的工作，不外乎寫測試計畫、測試策略、測試案例，
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 最近真的忙爆了！新功能要手動測試、舊的功能要跑自動化測試，重點是新功能除了要瞭解原先的產品知識外，還需要瞭解新功能的內容與架構，再撰寫對應的測試計畫與測試案例，重點是原本負責的自動化測試常常動不動就在 CI 上面壞掉、而且測試環境還偶爾不穩定，我還要邊看分析失敗原因，才能確定是不是要修改測試程式碼。 常常處理其中某件事情，我的一天就過了，啊啊啊……下禮拜又是 sprint 的最後一天了，如果有個同事能夠幫我就好了，於是我決定撰寫一篇徵人啟事，讓我自己不需要再處理這類的事情，只需要在關鍵時刻找我判斷就好。 徵人啟事 首先，我希望這位同事能自行探索、判斷問題：只要給予目標與條件，他即可找出問題並記錄結果。當然，在自動化測試盛行的時代，他必須能撰寫測試腳本、理解產品知識，並在檢視錯誤後自行修復失敗的測試。 為什麼要找同事，而不是更好的工具？差別不只在功能，而在誰負責決定下一步。一般工具等你操作，遇到預期外的結果，通常還是由人判斷原因與接下來怎麼做；同事則可以接住一個目標，自己尋找解決方案，遇到超出權責的情況再停下來詢問。常常我們缺的不是更多工具，而是一個能幫你扛掉重複工作的
測試策略的全知讀者視角：從金字塔到 AI 時代的多次轉變 本文由作者撰寫主要觀點，AI 協助資料蒐集、結構編排與文字潤飾，最終由作者審定。 前言 在現代軟體開發中，測試已不再是開發完成後才啟動的獨立階段，而是必須貫穿整個開發流程的核心實踐。 但隨著前後端分離、微服務架構的普及，以及 AI 輔助開發的崛起，「應該怎麼分配測試資源」這個問題也開始有了不同的答案。測試金字塔（Testing Pyramid）作為敏捷時代的經典模型，正在被測試獎盃（Testing Trophy）、測試蜂窩（Honeycomb）、測試鑽石（Diamond）、測試螃蟹（Crab）等新模型挑戰與補充。 本文將從歷史脈絡出發，梳理這些模型的起源、適用場景與侷限，幫助你在不同的架構與團隊情境下，做出更合適的測試策略決策。 測試金字塔 起源與架構邏輯 測試金字塔最早由 Mike Cohn 在其 2009 年的著作《Succeeding with Agile》
前言 常常上線前三天才開始測新功能，結果一跑測試才發現功能與當初的文件不符合，於是開始與 PM 和開發釐清，花了幾天的時間，才搞清楚功能規格，但上線日期不會因為這些事情而延後，但我的下班時間會？ 我曾經試著將測試左移引導至開發流程裡，對於釐清使用者需求的效果不錯，但涉及團隊的開發習慣、公司組織架構與產品特性，落地的困難度不一。如果你和我真的很想準時下班，我們可以來重新看看「測試左移」會不會是測試工程師準時下班的救星。 測試左移的起源與定義 要理解左移能不能真的幫上忙，先看看它從哪裡來。 2001 年的時空背景 測試左移在 2001 年被提出，想要理解為什麼被提出，需要先理解當時的開發環境。首先要介紹瀑布模型（Waterfall Model）和 V 模型（V-Model）這兩個當時主流的開發模型。 瀑布模型（Waterfall Model） 由 Winston Royce 在 1970 年的論文中首次描述（諷刺的是，Royce 本人其實是在論述這個模型的缺陷）