哪些該交給自動化軟體測試 Agent 負責
依據一次程式碼變更建立測試案例。 程式碼寫下的當下它就握有完整脈絡，而那正是細節最清晰的時候。
執行與重跑測試。 純屬機械性工作，讓人介入這個環節只會增加延遲。
初步判定明顯的失敗。 環境掛掉、相依套件缺漏、目標連不上。這些都不需要判斷力。
為它遇到的 bug 寫出重現案例。 測試案例在 bug 還在手上時就寫好，而不是三天後才躺在一張工單裡。
哪些該留在自己手上
「正確」的定義
模糊的需求是產品決策。Agent 會挑一個看起來合理的解讀，然後把它永久寫進測試裡。
哪些問題該擋下發布
今天哪些失敗才算重要，需要的是任何文件裡都沒有寫的脈絡。
這項檢查是否誠實
去讀測試計畫。當你要求 Agent 交出綠燈，它可能會用最短的路徑給你綠燈。
一句話講清楚這條界線
讓它決定怎麼驗，你自己決定什麼才該成立。這樣的切分很乾淨，剛好對應雙方各自真正擅長的部分，而且放進真實團隊裡也撐得住。
值得設下的護欄
每一項檢查都應該指名一個具體可觀察的對象，而且你至少要親眼看過它失敗一次。模糊的檢查等於邀請 Agent 去滿足檢查本身，而不是修好產品，而這種失效模式本質上是無聲的。
第二個月會出什麼問題
用這種方式運作的頭幾週通常很順利，之後則會出現一段可以預期的低潮，值得事先做好準備。
Agent 已經建立了一百個測試案例。多數都算合理，沒有人全部讀過，其中兩三個斷言的東西有著細微的錯誤。從此只要產品做出正確的變更，這兩三個案例就會失敗，於是大家開始覺得紅燈的意義變得模糊。接下來就是熟悉的滑坡：先重跑，再跳過，最後直接忽略。
只要按表操課、而不是等到出事才處理，這個介入的成本其實很低。每個月一次，把上次檢視之後新增的每個測試案例的斷言讀過一遍。不看步驟，只看斷言。以這樣的數量來說，花不到一小時，而且剛好能揪出那些否則會侵蝕整套測試信任度的案例。
設定方式
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，TestSprite 儀表板也提供同樣的設定方式。其餘的 CLI 功能都收錄在 CLI 儲存庫。
從儀表板連接儲存庫，測試就會直接對你原本就會產出的部署執行；或者，你也可以改成在自己的工作流程裡加上一個步驟。
TestSprite 負責什麼，什麼仍然屬於你
它負責「怎麼做」：依據變更建立測試案例、對已部署的應用程式執行測試、重跑，以及判定那些機械性的失敗。設定過程會把驗證技能安裝到你的程式開發 Agent 裡，讓這一切都發生在你實際工作的地方。
你保留「什麼」：讀測試計畫、修正那些即使產品已經壞掉也依然會成立的斷言，以及決定哪些失敗該擋下發布。在一般的量能下，這大約是每週一小時，而這正是你對產品的理解進入整套測試的地方。
這樣切分的好處是：重現案例會在 bug 還在手上時就寫好，而不是三天後才躺在一張工單裡；回歸測試的涵蓋範圍，也是從真正出過的問題長出來的，而不是來自紙上的規劃作業。
Agent 可以在無人監督下運作嗎？
就執行測試和機械性的失敗判定來說，可以。但要決定什麼才該成立、什麼該擋下發布時，監督本身就是重點，而不是額外的負擔。
我們要怎麼避免測試無限膨脹？
像審查程式碼一樣審查建立出來的測試案例，並刪掉重複的。只有數量、沒有判斷，才是最主要的失效模式。
如果它寫出一個永遠不會失敗的檢查怎麼辦？
這種情況常見到值得先做好準備。在你依賴這項檢查之前，刻意把東西弄壞，確認它真的會變紅燈。
它需要存取儲存庫嗎？
它是透過介面驗證已部署的應用程式。程式碼本來就在你的程式開發 Agent 手上。
我們要怎麼衡量這套做法有沒有效？
看漏檢的缺陷，以及從失敗到修好所花的時間。測試數量會立刻上升，但幾乎沒有意義。