測試 Agent 的價值，取決於它的失敗訊息
一行紅字配一張截圖，預設了會有人去解讀它。堪用的失敗訊息會說清楚：嘗試做了什麼、應用程式實際做了什麼，以及兩者從哪裡開始分歧，而且要讓負責修的人不必自己拼湊來龍去脈就能動手。
當負責修的是程式開發 Agent 時，這一點的重要性加倍——它沒辦法看著截圖去推測你原本的意圖。評估時要求對方展示一次真實的失敗，而不是一次全綠的執行結果。
第二：這個檢查有沒有可能失敗
評估時刻意弄壞一個東西：讓儲存不再真的存進去，或讓篩選條件安靜地回傳全部資料。如果檢查依然一片綠，那它從頭到尾就沒真的接到你的產品上。
這件事有兩種出錯方式：一是檢查寫得太模糊，模糊到根本不會有明確結果；二是執行還沒跑到斷言就逾時，卻被回報成通過。第二種更糟，因為它看起來就像是已經涵蓋過了。
第三：它會不會不用人開口就自己執行
只在被要求時執行。 在一次工作階段中很好用，結束之後就消失了。
在變更時執行。 由 pull request 或部署觸發。這一種才真的在保護你。
依排程執行。 能抓到環境飄移，以及外部相依項目的變動。
一個只有被叫到才動作的測試 Agent，充其量是個比較厲害的手動測試人員；那不是沒有價值，但那不是你當初要買的東西。
第一週該觀察什麼
除了那三個特性之外，第一週還有兩個行為，能預測這件事最後會不會成功。
它建立出來的涵蓋範圍，反映的是你的產品，還是你規格文件的形狀。一個照著 API 文件工作的 Agent，會忠實地涵蓋每一個 API 端點，包括沒人在用的那些，卻會漏掉那條寫在註解裡的規則。讀過它產出的第一份計畫，就知道你拿到的是哪一種；而早點修正，遠比累積到兩百個測試案例再修正便宜得多。
還有，到底有沒有人在看那些失敗。測試 Agent 產生的訊號比手動流程多，而沒有人消化的訊號只是成本。如果一週之後，大家對失敗的反應是「知道了」而不是去追查，問題通常出在失敗訊息的呈現方式，而不是團隊本身，值得趁習慣還沒養成前就提出來。
半天就能做完的評估
描述三段流程。刻意弄壞一個東西。合併一次變更。如果它抓到了你弄壞的地方、把失敗講得夠清楚，而且不用人開口就注意到那次合併，它就是在做該做的事。這三項只要有一項不過，再長的功能列表也補不回來。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想安裝任何東西，儀表板也能做到同樣的事。命令列能做的其他所有事情，都在 CLI 儲存庫。
觸發時機比觸發機制更重要。把它接上你的部署事件，就代表每一次變更都會被檢查，不需要任何人特別決定； GitHub App 可以從儀表板做到這件事，而 GitHub Actions 的步驟則是在你的工作流程內部做到同樣的事。
TestSprite 怎麼回應這三點
失敗會以「嘗試做了什麼、應用程式實際做了什麼、兩者從哪裡開始分歧」的形式回傳，而且是程式開發 Agent 不必等人先解讀就能動手的形式。檢查會針對具體的東西下斷言，而沒跑到斷言就結束的執行，不會被回報成通過。它也會在變更時執行：接上儲存庫，測試就會從你的 pipeline 本來就會產出的那次部署開始跑。
涵蓋範圍由你的產品生成，再用自然語言調整；安裝過程會把驗證技能裝進你原本就在用的程式開發 Agent 裡，所以建立與執行檢查都發生在工作之中，而不是在工作旁邊另外做一件事。
你得到的，就是那套半天評估會通過：它抓到你弄壞的地方、把失敗講得夠清楚，而且不用人開口就注意到那次合併。
這和測試框架有什麼不同？
框架執行的是你指定好的東西。Agent 則會自己決定要檢查什麼，還能根據結果反覆調整——槓桿在這裡，審查的負擔也在這裡。
它需要存取我們的原始碼嗎？
它是透過介面驗證已部署的應用程式。你的程式開發 Agent 本來就拿得到原始碼。
生成出來的檢查需要多少審查？
第一次執行前先讀過計畫，並且把新的檢查當成程式碼看待。數量大卻沒人審查，是最主要的失敗模式。
它能修好自己找到的 bug 嗎？
它可以把一份堪用的失敗訊息交給程式開發 Agent，由它提出修正，再用同一套方式驗證。迴圈就此閉合；判斷權仍然在你手上。
執行的成本是多少？
每次執行都會消耗點數，所以在展開一段長時間的工作階段前，先把預期講清楚。一個手上有驗證工具的 Agent，是一定會用它的。