用戶驗收測試（user acceptance testing，簡稱 UAT），是新系統上線前，由實際使用者確認系統能否配合日常工作的階段。開發團隊的測試確認軟件按設計運作；UAT 則要確認系統符合業務需要，並配合員工和客戶實際的使用方式。對委託開發軟件的企業來說，UAT 往往是交付或上線前確認成果的主要機會。
UAT 與其他測試有何不同
軟件項目通常有幾輪測試，負責人和目的各有不同：
- 開發及 QA 測試：確認功能符合規格、程式運作正確，一般由開發團隊負責。
- 回歸測試：確認系統修改後，原有功能仍然正常。
- 用戶驗收測試：以真實的工作、資料和用戶角色，確認系統配合業務流程，由業務用戶負責或參與。
通過開發測試，不代表一定通過驗收。一張表格可以完全正常運作，但欄位次序未必配合前台同事接受預約的實際做法。
誰應該參與
參與 UAT 的，最好是日後真正依賴系統的人，而不只是項目負責人。視乎項目，可包括：
- 處理預約、訂單或查詢的前線同事；
- 負責審批、修改記錄或查看報表的主管或管理員；
- 核對金額、匯出資料和對賬的財務或營運同事；
- 在適當情況下，少量測試對外流程的客戶或會員。
開發團隊通常負責準備測試環境、說明如何報告問題，以及修正錯誤；系統是否可以接受，則由企業決定。
開始前要準備甚麼
- 驗收準則：以書面議定每項功能或流程怎樣才算「通過」，最好在訂立範圍時已寫好，而不是留到項目尾聲。
- 測試情境：簡短而貼近現實的任務，例如「為會員建立預約、更改時間，然後取消」，並列明每一步的預期結果。
- 測試環境：UAT 一般在與正式資料分開的測試或 staging 版本進行，即使操作出錯也不會影響實際業務。
- 測試帳戶及資料：為每個用戶角色準備帳戶，以及接近真實的樣本資料。除非已妥善議定，否則不要使用真實的個人或付款資料。
- 問題記錄方式：用共用清單或追蹤工具，記下操作步驟、預期結果、實際結果和截圖。
- 時間表：測試人員有本身的工作，要預留時間進行 UAT 及第二輪重新檢查。
以下示例僅供說明：一間公司以 Web App 取代用試算表處理的預約流程，請兩位前台同事和一位經理進行 UAT。開發團隊的測試全部通過，但同事發現，客人如果沒有電郵地址，系統便無法儲存電話預約。問題記錄後，雙方議定這屬於錯誤還是範圍改動，修正後於上線前再檢查一次。
為發現的問題分類
UAT 發現的問題不一定是錯誤，可以先分類：
- 錯誤：系統沒有按議定內容運作。
- 改動要求：系統按議定內容運作，但業務現在需要不同做法。這類要求可能影響時間或費用，應另行議定。
- 疑問及培訓需要：功能已經存在，只是用戶不知道如何使用。
每項錯誤都應議定嚴重程度，例如會否阻礙上線，還是可留待之後的版本修正，讓簽收有清楚的優先次序，而不是只看問題數目。
簽收與上線之後
UAT 通常以簽收作結，即記錄系統可以上線的決定，有時會附上已知的輕微問題及修正安排。請確認協議中簽收代表甚麼，例如是否標誌保養期或支援安排開始。
UAT 只反映系統在某一時間的狀態。上線後的修改和更新，可能影響早前已驗收的功能，這時便需要回歸測試和持續的網站監察。簽收後的支援條款，通常寫在軟件支援 SLA 之中。如果你正開發第一個版本來驗證構思，可參閱 MVP 解說。
如需了解服務範圍，可參閱 technine.io 的網站及 Web App 開發服務，當中包括 UAT 及上線驗證。
常見問題
UAT 由客戶還是開發商負責？
通常雙方都有責任。開發商準備測試環境、支援測試人員及修正錯誤；企業負責或參與測試，並作出驗收決定。這些角色最好在項目開始前議定。
UAT 需要多長時間？
視乎系統規模、用戶角色數目，以及測試人員可以投入多少時間。最少要安排一輪測試和一輪修正後的重新檢查，並及早訂好時間表。
UAT 可以自動化嗎？
驗收決定要由人作出，因為這是判斷系統是否配合業務。議定流程的重複檢查則可以自動化，日後亦可用於回歸測試，詳情可參閱 technine.io 的自動化 UI 及用戶流程測試。