客製軟體 UAT 怎麼做
客製軟體的使用者驗收，是預定使用的人按驗收清單逐條操作，並把每條結果記成通過、缺陷、範圍變更或誤用。簽收只涵蓋有當次操作證據的條目，沒有證據的條目維持未驗收。
先有清單，再開始操作
驗收清單寫的是每一條結果要怎麼在示範或使用者操作裡被看見。那一份怎麼從規格產生，見 客製軟體驗收標準怎麼寫。規格本身怎麼寫結果、負責人與範圍外，見 客製軟體需求規格怎麼寫。本文只寫清單已經存在之後，怎麼跑一輪使用者驗收。
操作中想改某一條結果，不在會上改清單。那是範圍變更，見 客製軟體範圍變更怎麼管。交付範圍見 客製軟件、網站與應用程式。沒有清單、或清單指不出規格版本時，這一輪先不要開始。
大綱把使用者驗收放在驗收測試裡
ISTQB 認證測試員基礎級大綱 v4.0.1 的修訂表把 CTFL v4.0.1 標為 2024-09-15 的勘誤，把 CTFL v4.0 標為 2023-04-21 的正式版。第 2.2.1 節寫明，驗收測試著重於確認（validation），以及顯示是否已可部署，也就是系統是否滿足使用者的業務需要。理想情況下，驗收測試由預定的使用者執行。該節列出的主要形式包括使用者驗收測試（UAT）、營運驗收測試、合約驗收測試、法規驗收測試，以及 alpha 測試與 beta 測試。
同一節寫明，測試層級以測試對象、測試目標、測試依據、缺陷與失效、作法與責任來區分，以免活動重疊。公開的這一段沒有列出使用者驗收紀錄的欄位，也沒有給出通過比例或時限。本文不把沒有寫出的欄位算進大綱。下面的案例與紀錄，是購買方在驗收清單已經寫好之後用來跑這一輪的寫法。
案例對到清單上的一條
每一則案例寫八項：規格版本、驗收清單的條目編號、操作的角色、起始資料、操作步驟、系統應留下的紀錄、誰執行、執行日期。八項缺任何一項，案例留在草稿，不進入當次操作。
案例只覆蓋清單上已有的條目。聊天裡新增的句子、或「順便看一下」的畫面，不另開案例。它若要進入清單，先回到驗收那一篇補條目，或按變更那一篇另開請求。清單沒有寫的步驟，不當成這一輪的失敗。
操作、紀錄、簽收分開
操作的人是該條目已經寫明的預定使用者。紀錄的人寫下當次看見的結果與系統留下的紀錄編號，不代替操作的人宣佈通過。簽收的人是規格裡已經寫明可以收下這一版的那一位。三個角色可以有人重疊，紀錄上仍分三欄。
預定使用者缺席時，這一輪停在該條目，不由開發或在場的其他人代為操作後勾選通過。開發可以坐在旁邊指出畫面位置。勾選通過的是操作的人自己在紀錄上寫下的結果。
缺陷、變更、誤用分開記
缺陷是：操作的人按案例步驟做完，系統沒有留下該條目要求的紀錄。範圍變更是：操作的人要的結果與清單上的條目不同。變更另開請求，不把該條目改成剛剛說出口的句子，也不把變更算進缺陷。誤用是：操作離開了案例寫明的步驟或起始資料。誤用記入同一筆紀錄，不把該條目標成失敗，也不在會上把清單改寬。
三種結果各留自己的編號，並指回同一則案例。把三種都寫成「有問題」，下一輪就分不出該修系統、該改規格，還是該重做一次操作。
簽收前先留下證據
每一則已執行的案例保留：操作的人、日期、案例編號、看見的結果、系統留下的紀錄編號、以及通過、缺陷、變更或誤用四者之一。證據是當次畫面的截圖或系統匯出，並能對上那個紀錄編號。
口頭一句「可以」沒有寫進上述欄位之前，該條目維持未驗收。沒有紀錄編號的截圖，先補編號或標成證據不足，不進入簽收。
簽收只蓋有證據的條目
簽收寫明規格版本、有證據且通過的條目、以及仍開著的條目。仍開著的包含未執行、證據不足、缺陷未再跑過、以及已另開變更請求的條目。簽收不表示會上提過的每句話都已納入。
缺陷留到下一次操作看見該條目要求的紀錄，才改成通過。變更請求在核准之前，簽收版本維持當次的規格版本。把已經做出來的畫面回寫成當次通過，下一輪就失去對照。
什麼時候先不要簽收
驗收清單指不出規格版本、預定使用者還沒寫在條目上、或已執行的案例缺紀錄編號時，先不要簽收。先補清單、補角色或補證據。會上想把條目改成剛剛看見的樣子，同樣先寫變更請求。
本文不給出缺陷數、通過比例或驗收天數。數字若要寫，來自貴司自己的規則並註明日期，本文不代填。大綱的勘誤日期是 2024-09-15。沒有這一輪紀錄之前，用「每則案例是否指向清單條目、結果是否分成通過、缺陷、變更或誤用、簽收是否只蓋有證據的條目」來檢查驗收有沒有在按紀錄走。