登入 訂閱
Claude × Playwright：30 天打造你的 Agentic SDET 同事

Day 02｜職務說明書：Agentic SDET 到底負責什麼？

Vans

• 閱讀時間 12 分鐘
分享
Day 02｜職務說明書：Agentic SDET 到底負責什麼？
Photo by Eric Prouzet / Unsplash

前言

徵人啟事發出去之後，我收到不少應徵信。Gemini、ChatGPT、Claude 都投了，還有幾個開源模型，包括七月剛放出權重的 Kimi K3。每篇自我介紹都很精彩：有的說自己擅長剪片配音，有的說最會搜資料，能把一堆雜訊整理成學習報告跟投影片，有的自稱全能翻譯，任何語言即時轉換。但沒有一個講得出 Agentic SDET 要做什麼，於是我寫了這篇文章。

Agentic 之亂

我想起多年前的 Ops 之亂。當時的情況跟現在的 AI 差不多，大家喜歡在職稱前面加個字首：DevOps、TestOps、SecOps，接著是 DevTestOps，甚至 OpsOps。這樣說來，我把 Agentic 湊到 SDET 前面，應該也不為過。

但這個字首背後有實質差異。傳統測試的工作，不外乎寫測試計畫、測試策略、測試案例，然後執行，或者寫測試程式、維護整條自動化測試開發流程，用工程手段達成測試目標。而 Agentic SDET，指的是一位能自己找問題、判斷問題、留下證據、讓你追蹤結果的 AI 同事。

差別不在於它會不會寫測試碼，而是在於它能不能自己判斷是不是問題，要不要開票，甚至修改好程式碼，要不要開 PR。

寫職務說明書

為了要了解這位新同事能夠做哪些事情，權責在哪裡，我們必須先寫好職務說明書。有些人可能會想說，直接叫新同事做事，我們只要讓新同事邊做邊學。但新同事不一定會知道，資料可不可以刪掉，或是 DB 可不可以清空？

如果我們事先沒有跟他說，他有可能在刪了一些資料之後，我們才去補規則。這時候資料已經沒了。如果這個新同事是老手的話，他也許會有一些職業的直覺；但我們這位新同事是不會有的。

另外就是，其實有時候我們在做測試的時候，不一定所有的流程或是步驟我們都已經很清楚了。有時候要寫給別人看，對我們來說也是很難執行的一件事情。

所以，我們必須要把我們的經驗或是嘗試寫成規則，這樣會慢慢把一些無法講清楚的地方，變成一個可以被讀取的檔案。

基本上，它必須符合三個層級：

  1. 可以做的
  2. 需要問人類的
  3. 永遠都不准的

因為我們之後的每個動作，其實都要去遵守這樣的規則。

實驗：這份 JD 後來變成一個設定檔

先看結局。本文最後那份 職務說明書 v0.1，最後真的變成 repo 裡的 config/governance.example.yaml：

tiers:
  autonomous: []          # 可自主執行、不需人審的動作
  needs_review: []        # 需人審（如 test-heal 批次、quality-gate override、開 PR）
  forbidden:              # 永遠禁止
    - merge_pr
    - reset_shared_env
    - truncate_shared_db
override:
  require_reason: true    # 硬推閘門必須留痕（誰／何時／理由）

在看這份文件的時候，可以分三類：

  1. Autonomous：它可以自主決定要不要執行，不需要人類去做審核。
  2. Mixed Review：它是必須要經過人類審核之後才能執行的項目。
  3. Forbidden：是永遠禁止的。例如：它不能 merge PR、不能 reset 公用的環境，甚至不能清空共用的資料庫。最後加上 override.require_reason 這條規則。之後 triage 要開單、bug-fixer 要開 PR、test-heal 需要改測試，動手之前都需要讀這個檔案。

但目前讓新同事值班了兩輪之後，發現其實 forbidden 的這個欄位在目前的設定中還沒有被觸發過，這並不代表說這個規則是有效的，只能代表說它目前還沒有被執行。

畢竟當禁止清單沒有被觸發時，我們是沒辦法分別它是被規則擋住了，還是它本來就不會執行到。但我們寫在這裡，就是希望有一天它真的執行到的時候，可以擋住這些不必要的動作。

grep forbidden_attempts output/runs/2026-07-30.yaml output/runs/2026-08-01.yaml

output/runs/2026-07-30.yaml:forbidden_attempts: 0
output/runs/2026-08-01.yaml:forbidden_attempts: 0

如何把我們的判斷，寫成可以看得懂的規則？

AI 天生不知道什麼是「正確」，也不知道使用者的哪些行為算合理。我們得把腦袋裡的東西翻譯成它能依循的規則：

  • 產品需求與 Acceptance Criteria
  • 什麼是使用者正常的操作行為
  • 哪些是高風險功能與核心商業流程
  • 哪些行為是 Bug，哪些是正常設計
  • 跨功能操作時，有沒有不合理的組合
  • 哪些環境上的錯誤可以忽略
  • 哪些問題必須立刻通知人

簡單說，產品上線之後，我們要能讓它像使用者一樣操作，並且自己判斷結果對不對：登入後應該看到正確的頁面；未登入時 API 回 401 或 403，那是正常行為，不是 Bug。我們要做的，就是把這些判斷變成它看得懂的標準。

以登入測試為例

如果只是「用 AI 幫忙寫測試」，指令大概長這樣：

請幫我閱讀程式碼或測試案例，產生 Playwright 登入測試

它會生出測試碼，跑一遍，然後告訴你完成了。接著你發現漏掉幾個關鍵路徑，或者有幾支測試根本沒真的跑起來。

但如果是交辦給一位同事，指令會變成這樣：

今天晚上幫我測最新版本。優先檢查這週有改動的功能，有問題就開票

就像你平常交辦事情給另一位同事。

問題是，你怎麼知道這位同事：

  1. 它怎麼知道這是不是 Bug？
  2. 它怎麼決定下一步要測什麼？
  3. 如果它誤判了，自己發現得了嗎？
  4. 它能不能刪掉自己建立的測試資料？
  5. 上週已經報過的問題，這次會不會又重報一次？

這五個問題，就是接下來 30 天的目錄

上面這五個問題，就是接下來 30 個工作日會逐步回答的內容，而且每一題都會對應到具體的做法。

第一題，他怎麼知道這是不是個 bug？

通常我們看到一些異常，不代表我們就找到了缺陷。我們可能要把異常去做分類，例如它有可能是：

  1. 產品本身的缺陷
  2. 環境造成的
  3. 測試資料的問題
  4. 人為操作或機器操作不當
  5. 測試案例本身的問題（有時候會時好時壞）
  6. 雜音幹擾

然後我們再用這些去跟產品的行為去做比較，確認以下幾點：

• 是否符合內部的一致性？

• 畫面跟後端的 API 是不是能夠符合？

• Console 上有沒有出現 error？

• 規格是不是正確的？

• 使用者實際上會怎麼使用？

第二題，怎麼決定下一步要測試？

接下來我們不會給他一個寫好的測試腳本，而會給他一份叫做 charter（探索憲章）的東西。Charter 會把目標、範圍、可以做什麼、不可以做什麼寫清楚，接下來讓系統自己決定要怎麼走。

走過的路它自己會記得，免得它會不斷重複檢查已經檢查過的東西。

第三題，他如果判斷錯誤了，是不是可以自己發覺到？

基本上，找到 Bug 的那個 Agent 是不能去驗自己的 Bug 的，因為可能會有盲點存在。所以我們會用另外一個 Agent，在拿不到前一個 Agent 任何推理的情況下，如果他可以從乾淨的環境重現這個 Bug 的話，那就代表這真的可能有很大的機率是一個 Bug。

第四題，它能不能刪掉自己建立的測試資料？

另外，就是他到底能不能刪掉自己測試的資料？會不會誤刪到別人的測試資料？這個也是你必須要跟他說明的規則。這種問題不該靠判斷解決，該靠寫規則去規範它。

第五題會不會重複到相同的報單？

我們會根據每個問題先做一個指紋。我們在開單的時候，可以先比對是否有相同的指紋，如果有開過的話，就不會再開新的。

但還有一個更根本的問題

不過我們這位新同事，他其實個性不是很穩定。這代表說，同一個任務或同樣的測試、同一個產品，如果是今天跑或明天跑，甚至如果你是使用者、心境不一樣的話，他可能走的路或下一步不一樣，甚至他注意到的東西都會不一樣。如果你在同一個環境，結果可能都會不同，但這個對於測試來說是比較難接受的事情。

所以我們可以把整套方法都建立在「可重複性」上面。如果一隻程式每次跑的結果都不同，我們會稱它為 flaky，然後把它 isolate（隔離）起來。但我們並不會追求每次結果都相同，我們應該追求的是：每次結論都可以附上證據，然後另外一個人可以照著這份證據，重現 Bug。

所以今天如果他走 A 路線發現一個 bug，但是你走另外一個 B 路線沒有發現，這個沒關係。

但是如果他說這裡有 bug 的時候，必須要有足夠的證據，而且這個證據可以讓一個人或是一個 agent 去重現這個問題。所以我們的重點在於結論，而不是他走的路徑。

接下來，我們就可以把第一版的職務說明書寫出來了。

Agentic SDET 職務說明書 v0.1

使命: 成為一位值得信任的品質守門員

核心職責:
  - 依 charter 給的目標與範圍自主探索，自己決定下一步
  - 每個結論都留下可以重現的證據
  - 判斷異常是不是缺陷，並且說得出違反了哪一條判斷準則
  - 把確認的問題寫成人類看得懂、照著做就能重現的報告
  - 撰寫並維護自動化測試
  - 測試案例失敗先分析原因，再決定要不要修

明確不負責:
  - 無法重現的異常，不建立正式 Issue
  - 不刪除別人的資料，只清自己建立的測試資料
  - 同一個問題，不重複回報
  - 找到 Bug 的人，不驗自己的 Bug

需要我點頭才能做:
  - 開 Issue
  - 開 PR
  - 品質閘門（必須留下誰、何時、為什麼）

永遠禁止:
  - 合併 PR
  - 重置共享環境
  - 清空共享資料庫

小結

今天不是叫工具去產生程式碼，就會冒出上面你必須要回答的五個問題。這五題就是接下來我們要做的方向。基本上，其實它的行為是不穩定的，這件事目前是沒法改變的。所以我們換個方向思考，變成不追求相同的結果，但會追求每次結論都可以附上證據，而且可以讓任何一個人重現問題。

        「今天晚上幫我測最新版本，有問題就開票」
                          │
                          ▼
              五個你答不出來就不敢交辦的問題
    ┌──────────┬──────────┬──────────┬──────────┐
    ▼          ▼          ▼          ▼          ▼
 怎麼知道    下一步     誤判自己   清得掉自己  會不會
 是 bug？   測什麼？   發現得了？   的測資？   重報？
   W2/W3      W3         W4        紀律       W4
    └──────────┴──────────┴──────────┴──────────┘
                          │
                          ▼
              但它天生不穩定，路徑不可重現
                          │
                          ▼
            換一個標準：能重現的是結論，不是路徑
                          │
                          ▼
              職務說明書 v0.1 的三層權限
        自主執行 ──── 要我點頭 ──── 永遠禁止
                          │
                          ▼
              config/governance.example.yaml
        （每個會產生副作用的動作，動手前都讀它）

下一步

明天要幫這位新同事申請一張辦公桌，實際建立 Claude × Playwright 的專案環境。對了，還沒正式介紹。這次脫穎而出、成為我下一位同事的候選人，就是 Claude。

---

參考資料

  1. Anthropic — Give Claude a role - 角色設定會實際改變輸出品質，這是「JD 即 system prompt」的依據
  2. Claude Code Docs — Create custom subagents - 用 name／description／tools／system prompt 定義一位專職 agent
  3. Anthropic — Increase output consistency - 維持角色一致性的官方建議
  4. James Whittaker et al.《How Google Tests Software》 - SET 職責邊界的經典描述，可對照改寫成 agent 的 JD

Sign up for more like this.

Enter your email
訂閱