UX 與 UI 測試問的是兩個不同的問題
| UI 測試 | 按鈕有沒有把紀錄存下來。清單有沒有重新整理。可客觀驗證。可自動化。每次改動都該執行一次。 |
| UX 研究 | 使用者找不找得到那顆按鈕。他們看不看得懂結果。這需要真人。無法自動化，也不該假裝做過。 |
一個產品可以通過每一項 UI 測試，用起來卻痛苦不堪；也可以在可用性測試中讓人驚豔，上線後卻搞丟資料。兩者誰都無法取代誰。
自動化真正扛得起的部分
每一條流程的功能正確性。 也就是第一欄的全部。
機械式的無障礙檢查。 缺漏的標籤、對比度、焦點順序。確實有價值，但不等於無障礙的全部。
一致性檢查。 同一個操作在三個地方的行為是否相同；這是一種有可測試形式的 UX 問題。
它做不到的部分
這條流程講不講得通。那則錯誤訊息有沒有幫上忙。有沒有人中途放棄。這些都需要真人；比較有用的想法是：自動化拿掉了人工回歸測試那一輪，把做這些事的時間買了回來。
值得自動化的那塊重疊地帶
兩者確實有一小塊真正交會的地帶，而對多數團隊來說，這是現成卻最少被用到的自動化。
一致性是一種有可測試形式的 UX 屬性。同一個操作在出現的三個地方，是不是都給出同樣的確認訊息。錯誤在每個地方看起來都像錯誤，還是某個畫面默默失敗。主要操作在每個彈出視窗裡是不是都在同一個位置。這些都不需要判斷設計好不好，卻全都是使用者會察覺為「做得隨便」的地方。
對做出各個畫面的人來說，這些問題也是看不見的，因為每個畫面在自己內部都是一致的。跨畫面檢查的成本很低，而且能抓到一整類的抱怨——那既不是功能測試在找的，也不是可用性研究在找的。
陷阱
團隊因為 UI 測試覆蓋率很高，就砍掉 UX 研究。這個推論聽起來合理，其實是搞錯了類別：覆蓋率說明的是產品有沒有做到它被打造出來要做的事，卻完全沒說那件事是不是該做的事。
比較健康的分工是：重複性的檢查交給自動化，省下來的工時投入只有真人才做得到的研究。
這些都不需要用到終端機。在 TestSprite 儀表板建立一個專案，用白話描述要檢查什麼，再把它指向你的應用程式。團隊裡的開發者如果偏好指令列，也可以用同一套東西，相關內容都在 CLI 儲存庫。
觸發的時機比機制更重要。把它掛在部署事件上，等於每一次改動都會被檢查，而不必有人特別決定要跑； GitHub App 就是從儀表板做到這件事，而一個 GitHub Actions 步驟則是在你的工作流程內部做到同樣的事。
TestSprite 自動化了哪些事，又把哪些留給你
它把整個功能那一欄都自動化了：流程跑不跑得通、狀態在各步驟之間有沒有正確傳遞、告訴使用者的內容和實際發生的事是否相符。測試案例由你的產品生成，並以白話語言調整，每次改動都會執行。
它也涵蓋位在重疊地帶的一致性檢查，例如同一個操作在每個出現的地方行為是否相同——這是一種有可測試形式的 UX 抱怨。
它刻意留給你的，是研究。拿掉人工回歸測試那一輪，價值就在於它還回來的工時；而這篇文章的主張是：那些工時應該拿去跟使用者對話，而不是又回頭填進待辦清單。
AI 可以做可用性測試嗎？
它可以模擬走過介面的各種路徑，這對覆蓋率很有幫助。但它無法告訴你真人會不會被搞混，因為那是關於人的事實。
無障礙屬於 UX 還是 UI？
兩者都是。機械式的部分很適合自動化，體驗層面的部分需要真人，最好是實際使用輔助科技的人。
UX 研究應該多久做一次？
當產品有重大改動，或數據顯示使用者正在流失的時候。不必為了做而按固定週期做。
這兩件事各自由誰負責？
UI 測試通常由工程團隊負責，UX 研究則落在設計或產品那邊。問題往往出在大家以為某一個團隊把兩件事都顧到了。
好的 UX 能減少 UI 測試的需求嗎？
不能。設計再好的流程，一次程式碼改動照樣可能把它弄壞，而這正是 UI 測試要抓的東西。