Claude × Playwright：30 天打造你的 Agentic SDET 同事

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 30｜三十天後，這位新同事能幫我做多少事？

前言 到 Day 29 為止，探索、判定、開單、修復、測試、CI、分流、flaky 各自都跑得動了，但每一段還是你在按下開始。今天把它們串成一條線交出去：哪些動作它自己做、哪些要先問你、什麼情況必須停手，全寫進授權分級。 開始之前 前面二十九天累積了一整套能力。但只要每一段都要你發動，這位同事就還是一個很好用的工具，不是一位同事。 這一步要交出去的是流程的發起與接續：先由人安排排程或啟動一輪，代理人再依授權把各站接著跑完，不必每一步都由你下指令。本篇的實驗是手動啟動，沒有示範代理人自己設定排程。 但能接著跑，不代表什麼都能做。合併 PR、重置共享環境、清空共享資料庫，會影響別人正在使用的程式或資料，所以本流程不把這些動作交給代理人。 今天把授權分成三層：可自行執行、需要授權，以及本流程禁止執行。設定檔告訴代理人每個動作屬於哪一層，執行前必須檢查；工具端有沒有真的限制住，則是另一件要確認的事。 還有一件容易被忽略的事：值班要留下可稽核的紀錄。 一輪跑完，

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 29｜這支測試怎麼有時通過、有時失敗？

前言 昨天沿著紅燈留下的證據找原因，今天遇到的測試更麻煩：同樣條件下，這次紅、下次卻綠了。我們先決定跑幾次，再記下失敗次數，把「有時候會壞」量出來，交給後續流程處理。 開始之前 一支測試時紅時綠，最自然的反應是重跑一次。綠了，收工。 這個反應會製造兩種傷害。第一，訊號被關掉。 你用重跑蓋掉了一個真實存在的時序問題，它下週會再來，而且下次可能發生在真正重要的那一次發布前。第二，人開始不信 CI。 一旦「紅了先重跑」變成習慣，真正的產品回歸也會被重跑掉。 但 flaky 也不能拿 Day 28 那套處理，因為它不穩定，你沒辦法用一次觀察歸類。「它有時候會紅」不是可以行動的描述。 所以這一步的工作是把「有時候」變成一個數字：同一份程式碼、同一個環境，連續跑 N 次，紅了幾次。有了這個數字，

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 28｜測試在 CI 上失敗，我連續猜錯兩次原因

前言 CI 紅了，第一個反應常常是打開測試碼，改到它變綠。先等等，搞不好錯的是產品。今天拿昨天 clean 與 with-bugs 的結果做對照，再看每個失敗留下的證據，決定該找誰處理。 開始之前 一支測試紅掉，可能的原因至少十種：選擇器失效、等待條件不對、測資被別人污染、斷言過時、環境掛了、產品真的回歸、或者它根本就是時紅時綠。 這十種的處置完全不同。選擇器失效要改測試，產品回歸要開單，環境掛了什麼都不該改。弄錯類別的代價不是白做工，是做反了。把產品回歸當成測試過時去改斷言，等於親手把 bug 寫進規格。 還有一個更隱蔽的問題：太早認定原因，後面就容易只找支持自己的證據。 看到錯誤堆疊停在某一行，腦子立刻補完一段故事，然後照著改。改完測試綠了，也未必代表剛才猜對了。 所以這一步只做兩件事：歸類，然後指定誰該修，不動手。 動手試試 Day 27

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 27｜本機測試都通過了，放到 GitHub Actions 卻失敗

前言 昨天的測試跑在你的機器上，今天把它接進 GitHub Actions，讓相關程式碼更新時自動跑。同時把報告、操作紀錄和截圖留下來，免得 CI 紅了，大家只能對著一行錯誤訊息猜。 開始之前 本機跑測試有兩個問題，而且都不是「麻煩」而已。 第一，它只在你想到的時候跑。改完一段程式碼、趕著下班的那次，通常就是最該跑的那次。 第二，也是更嚴重的，本機的綠燈不能拿來說服任何人。你說「我這邊是綠的」，對方無從查證，也無從重播。CI 的價值不只是自動化，是它產生了一份別人可以檢視的紀錄。 但只把測試搬上去還不夠。CI 紅了，你能拿到的預設訊息可能只有一行 exit code 1，或一段沒有上下文的逾時。那種紅燈跟沒有紅燈差不多，因為沒有人能從它往下走。 所以這一天有兩件事：把測試接上去，以及讓紅燈自帶證據。第二件事的規格從 Day 8 到 Day

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 26｜替購物車寫支自動化測試

前言 前 25 天幾乎沒碰測試碼。Day 25 那支回歸測試是第一次動筆，而且是為了釘住一個 bug 才寫的。今天把它當起點正式寫測試，讓探索一次性找到的東西，變成每次都會重跑的東西。 開始之前 把測試放在第 26 天是刻意的。 寫腳本這件事，現在很便宜。你可以在 Day 2 就叫模型生一支會跑的 Playwright 測試，它會跑、會綠、看起來很像回事。真正的問題在下一層：這支測試在驗什麼，以及它綠的時候你能不能相信它。 前 25 天做的就是這件事。你先學會判斷什麼算異常、什麼算 bug、證據要留成什麼樣、結論怎麼被獨立重現。有了這些，你才知道哪一條路徑值得固化成測試，也才知道斷言該卡在哪裡。 順序反過來的後果很具體：先寫一大批測試，然後花整年維護一批你不確定在測什麼的東西。 還有一條決定要說清楚。多一支測試就是多一份要養一輩子的資產，所以 test-author

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 25｜第一次修 Bug，才發現原本的測試也錯了

前言 Day 24 放行之後，單開出去了。但有些 bug 不必等人排進 sprint，它自己就修得掉。今天讓它先重現、用先紅後綠的回歸測試釘住行為、最小幅度改產品碼，最後開一張 PR。開，但絕不自行合併。 開始之前 讓測試變綠最快的方法，是把測試改爛。刪掉那支測試、加個 .skip、把 toBe 放寬成 toBeTruthy，CI 立刻一片綠，PR 看起來很漂亮。 危險在於它跟真的修好長得一模一樣。報告上都是綠的，差別要打開 diff 才看得出來，而 diff 沒人逐行看。 所以修 bug 的順序不是流程建議，是防作弊機制。先重現，確定問題真的存在；再寫一支現在就會紅的測試，把「錯的行為」釘成一個看得見的失敗；然後才改碼，

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 24｜新同事找到八個問題，只有六個能開單

前言 Hunter 說是 bug、Verifier 說重現得了，還要再看一次開單需要的資料有沒有齊。今天請一位同事守在開單前，照六項清單逐一檢查，全部通過才放行。這就是 Issue Quality Gate。 當時的紀錄是 6 筆 pass、2 筆 hold。不過，這兩筆 hold 的分法有問題，下面會一起說明。 開始之前 前面五天立了一堆規矩：要有證據、要命中 oracle、要算分、要查誤報名單、要去重、要獨立重現。每一條當時都同意，問題是它們現在都只是好習慣。 好習慣會被跳過。趕著收班的時候、只差一條的時候、覺得「這個一看就是 bug」的時候，人會自己放行。放行一次沒事，第三次之後前面五天等於白做。 閘門的作用是把這六條從「最好有」變成「

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 23｜請另一位同事照步驟重做，確認 Bug 能不能重現

前言 讓新同事花了 30 分鐘竟然真的找出有問題的地方，可惡！這個地方我明明就測試了好幾次，甚至還有自動化測試涵蓋到，但新同事覺得有問題的地方，是不是真的是產品 Bug 呢？ 畢竟由我這個資深的前輩來判斷的話，可能有失公正。於是請另一位同事交叉比對，看看照步驟從頭操作一次，是否同樣的現象會出現。 開始之前 bug-verify 執行前會需要前一天留下的完整證據，而這份證據包含保留待測試網址、前置條件、操作步驟、看到的現象、原始證據，以及哪些東西不在這次測試的範圍內，並且把為什麼是 Bug 的理由、信心分數和結論都會拿掉。 由 bug-verify 執行完的結果會有三種： * 獨立重現成功（confirmed）：照著步驟重現問題成功 * 照著步驟跑不出來（not reproduced）：照著步驟無法重現問題 * 證據不足判斷（inconclusive）：證據不足於判斷這個問題 動手試試 昨天的完整證據整理一份給負責重現問題的同事的資料：保留受測網址、前置條件、操作步驟、看到的現象、

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 22｜讓 Bug Hunter 自己找問題，再交證據給我

前言 經過前幾天的培養，新同事終於可以當我的代理人，開始獨立處理事情了。之前得由我一步步下指令，今天可以讓它照流程自己跑，最後列出結果，再讓我幫忙審核就好。 這一步也是為了將來輪值做準備。輪值時我可能不在身旁，新同事得靠自己處理，總不能每一步都停下來等我，畢竟我可不想在半夜的時候被叫起來上廁所。 回歸正傳，前面幾天我們已經學會怎麼探索問題、判斷是不是 bug、打信心指數，以及去除重複的問題。今天把這些步驟串起來，交給一位代理人（Agent）執行。 我們只需要給它一句話，它就會跑完整個流程，交回候選問題和證據，讓我這個資深的前輩審核。不過，今天先讓它找問題、交證據，開單的權限還沒給它，後面再說。 開始之前 bug-hunter 開跑前會先檢查三件事，缺一項就先停下來補齊： * charter（探索任務書）檔案存在且可讀：沒有 charter，代理人不知道要巡查哪個範圍、邊界在哪裡。若沒有，先叫 exploration-charter 產生一份 charter。

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 21｜報過的 Bug 別再開單，誤報也要記下來

前言 Day 20 的分數只管單筆。可是跑多輪之後，同一個症狀會被重複撿到，判錯的那幾筆也會一再回頭。今天處理兩件事：確認過的誤判記進名單別再報，同一個指紋認得出來就不開第二張單。 為什麼需要去重與誤報名單 Day 20 的分數解決「哪一筆先看」，但它一次只看一筆。跑到第四輪你會發現另一個問題：同一個 bug 被撿到四次，四筆各自都拿到 high，分數看不出它們其實是同一件事。 本專案的索引現在是 18 張單，背後是 34 次觀察。不去重的話，issue tracker 收到的是 34 張，其中有 4 張都在講數量欄。開發者打開 tracker 第一件事不是修 bug，是先花時間判斷哪幾張是同一張。 誤報是另一個方向的浪費。有些症狀已經有人拍板過不是缺陷，例如未登入頁面打 /users/me 回 401。

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 20｜新同事報了八個問題，我該先看哪個？

前言 Day 19 放手跑完三輪，它交回三份檔案、七條 Oracle，判了三條 FAIL，還附上 needs-spec 與 inconclusive。問題是這些判定全出自它自己的嘴。今天替每一筆發現標一個信心指數，把「它說有問題」換算成「你要不要親自看一眼」。 為什麼需要信心指數 一輪探索交回來的東西是混在一起的：pass、fail、needs-spec、inconclusive、順手撿到的異常。你沒有時間逐筆讀完再決定要不要處理。 沒有分數只剩兩個選擇，兩個都不能用。全部自己看，Day 19 的放手等於白放；全部相信它，issue tracker 兩週就被塞爆。 分數的工作是排序與分流：哪些高到可以自動送去獨立驗證，哪些進人工佇列，哪些只留紀錄不往下走。 還有一個副作用同樣重要。要算分就得列出憑哪幾個因子，這逼它把「我覺得是 bug」拆成「複現幾次、

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 19｜讓新同事自己測一輪，結果卡在登入頁

前言 前幾天我們給了新同事一份 charter，他學會自己選下一步，也學會去挑戰那些不在正常路線上的流程，最後還會判斷自己看到的東西算不算問題。 今天把這些接起來跑一次。我們只給目標，中間不插手，最後看他交回來什麼。 這篇不介紹新的 skill，跑的還是 explore。差別在於前四天是拆開來講每個零件，今天是完整走一遍，然後學會怎麼審。 為什麼放手之前要先定死交付物 放手最常見的失敗不是它做錯事，是它做完了你不知道該看哪裡。過程沒人盯，你手上只剩它交回來的東西，那批東西如果沒有固定形狀，審這件事就無從開始，最後只能整段重跑一次，等於沒放。 所以管控點要從過程搬到交付物：事前把目標、判準、邊界寫死，事後只審那三份檔案。交出去的東西定死了，中間怎麼走才可以完全不管。 放手不是把電腦推過去就走。要交出去的只有三樣，全部寫在 charter 裡： * 目標：goal 與 scope，這輪要走哪些畫面、找哪一類問題 * 判準：oracles，憑什麼說某個行為是錯的 * 邊界：out_of_