UI 測試工具檢查一：改版時會發生什麼事
這是任何瀏覽器測試套件都逃不掉的長期成本，而各家工具的差距極大。如果測試步驟寫的是 DOM 裡的路徑，純粹的外觀調整就會讓整套測試變紅；如果步驟表達的是意圖，多半不會。
請要求廠商具體示範這一點，而不是用嘴巴描述。
檢查二：第兩百個測試由誰來寫
前十個測試是在評估期間，由一位有動力的人寫出來的。六個月後，多了四十個新畫面，當初的推動者也已經離開，誠實的答案往往是：沒有人。大多數被放棄的測試套件，都是死在這裡，而不是死於技術問題。
檢查三：失敗報告在修的人眼中長什麼樣
一張螢幕截圖加上一段堆疊追蹤，預設了會有人去解讀它們。但現在負責修的愈來愈常是 coding agent，而它做不到這件事。一份說明「嘗試做了什麼、應用程式做了什麼、兩者在哪裡分歧」的失敗報告，人和 agent 都能直接拿來行動。
檢查四：一次沒跑到任何斷言的執行，會被回報成通過嗎
請在試用期間刻意測試這一點，因為答案有時候真的是「會」，而這會讓其他所有評估都失去意義。如果一套測試在斷言之前就逾時、卻仍然回報綠燈，那它比沒有測試更糟，因為它產出的是信心，而不是資訊。
值得實際跑一次的練習
真的弄壞一個東西。例如一個不再寫入的儲存功能，或是一個安靜地把全部資料都回傳的篩選器。然後看每個候選工具的反應：它會失敗嗎？失敗訊息有沒有指出真正的分歧點？負責修的人能不能直接從那份輸出開始動手？花上半天，得到的資訊比比較一個月還多。
關於失敗，具體該問什麼
每家廠商都會給你看一次成功的執行。任何 demo 中最有價值的五分鐘，是要求看一次失敗的執行，而且有三件事要看。
輸出有說明「預期應該是什麼」，還是只說了「實際發生了什麼」？一份只放上壞掉頁面的截圖、卻沒說本來該長什麼樣的報告，等於把解讀的工作丟回給你。
不用看影片，你能不能判斷它是在流程的哪一步失敗？影片是很好的補充，但拿來當主要資訊來源很糟，因為在兩分鐘的錄影裡來回拖拉找那個瞬間，正是你當初想省掉的工作。
還有，agent 能不能直接根據它採取行動？修 bug 的愈來愈不是人，而這件事對「好的失敗報告長什麼樣」的改變，超過過去十年裡的任何其他因素。
每一種工具都躲不掉的成本
選擇器
一次完全不影響功能的改版，就讓整套測試變紅。
多數維護時間真正花在這裡。
等待
固定的等待時間既慢，又一樣不穩定。正確的等待方式，必須知道自己在等什麼。
大部分的不穩定都能追溯到這裡。
人工撰寫的覆蓋率
你涵蓋到的是有人寫出來的部分，也就是那些有意思的流程，而不是那些真的會壞掉的流程。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，TestSprite 儀表板裡也有同樣的設定流程。CLI 的其餘功能請見 CLI 儲存庫。
如果這條 pipeline 屬於另一個團隊， GitHub App 是阻力最小的做法：它就是一個 webhook，不會更動你儲存庫裡的任何東西，並且會在你的建置回報新版本上線時觸發。如果你希望這個檢查直接顯示在儲存庫裡，一個 GitHub Actions 步驟就能做到。
TestSprite 如何回應這四項檢查
改版時，以意圖表達的測試步驟能撐過外觀調整，所以不會因為某個按鈕換了位置就整套變紅。第兩百個測試不是人寫出來的，而是從你的產品生成，再用白話語言調整。失敗報告會說明嘗試做了什麼、應用程式做了什麼，以及兩者在哪裡分歧，coding agent 和人都能直接使用。而一次從未執行到斷言的測試，不會被回報為通過。
第四點值得你在任何試用期間親自驗證，包括這裡。弄壞一個儲存功能，讓它不再寫入，然後確認檢查確實變紅。
你得到的，是在團隊出貨速度快過寫測試速度時仍跟得上的測試覆蓋率，以及一個大家願意持續去看的失敗訊號，因為它大多是真的。
瀏覽器支援重要嗎？
先看你的分析數據。很多團隊花錢買的，是幾乎沒有使用者在用的瀏覽器覆蓋率。
開源還是商業方案？
授權很少是主要成本。撰寫與維護才是，而這兩者無論選哪一邊都差不多。
之後還能遷移嗎？
假設測試無法移植。請依照你預期一年後所在的位置來選擇，而不是打算之後再換。
試用期該多長？
長到足以涵蓋一次改版或一次真實的回歸問題。少了這兩者，你評估的只是 demo。
如果我們需要不只一套工具呢？
這很常見，也沒問題。用程式碼框架處理刻意設計的流程，再用生成的測試補足廣度，是很正常的搭配。