距離第一次 UAT 前，剩下四天

6 月 27 日，指揮中心第一次完成一整批需求，還剩下一些小功能調整後，7 月 1 日，系統就要交給第一批 UAT 人員使用，倒數四天。

這四天裡，我先把 13 項功能的 JSON 全部重跑一次，確認核心輸出符合預期。接著還要準備兩輪 UAT。兩輪加起來共有 13 個情境，涵蓋當時的 13 項功能。

參與者登入 DAP，依照平常的工作方式申請權限、審核、分派、處理與結案。我要確認這套開發方式做出來的平台，能不能支撐真正的申請與單據流程。

這套平台服務超過 100 位使用者。一個欄有問題或是其他意外狀況，上線後都可能影響每天處理權限申請的整群使用者。

規劃兩輪 UAT，找的人不同

我把 UAT 分成兩輪。

第一輪由熟悉跨科流程的人驗證。他們知道一張申請送出後，應該經過哪些角色、分到哪些組別，以及什麼狀態才能往下走。

第二輪交給申請人。他們關心的是入口找不找得到、欄位看不看得懂、按鈕放得順不順，以及返回上一步後資料還在不在。

這兩群人看同一套系統，會看到不同的問題。

熟悉流程的人能指出案件送錯組、卡在某個狀態，或處理人收到單據後不知道下一步。申請人則會直接卡在一個工程師早已習慣的欄位名稱，或按下一個我以為很清楚的按鈕。

UAT 的目標也因此變得具體：第一輪確認 DAP 的申請與單據流程能不能跨角色走完，第二輪確認申請人能不能順利完成操作。

ISTQB 對 UAT 的說明，也把重點放在預定使用者能否在實際或模擬的工作環境中完成需求與業務流程。這正是我這兩輪要驗的範圍。(ISTQB, Certified Tester Foundation Level Syllabus)

13 個情境要寫清楚角色、起點與完成點

情境名稱只能告訴測試者要驗哪個功能。真正開始操作前，還要補齊角色、資料、起點和完成點。

我會先整理這些內容：

其中最重要的是「完成點」。

DAP 的新流程會經過申請、主管覆核、預算審查、執行主管分派、執行人處理，再回到申請人確認。只寫「成功送出」會漏掉後面一大段。

第一輪 UAT 要一路看到案件是否交給正確角色、狀態是否往前推、工作單能否完成，以及申請人最後能不能收到結果。每個人只看自己那一頁，整條流程仍可能在中間斷掉。

我的兩個卡控點，管的是開發

前面幾篇提過，我在開發流程中保留兩個人工卡控點。

第一個在 Plan 完成後。我確認需求範圍和技術做法，確定 AI 接下來做的是我要的功能。

第二個在開發與驗證完成後。我看最後畫面、流程和輸出，完成這一版的定版確認。

完成第二個開發卡控點後，我把 DAP 版本交給各科流程人員與申請人進行 UAT。

前兩個卡控點確認開發工作有沒有照需求完成；兩輪 UAT 確認 DAP 平台能不能讓各科人員與申請人完成實際作業。

四天內，我要把問題變得能接回來

UAT 期間內若有發現問題，還要有人接回開發流程。

所以問題回饋很重要，每一筆回饋至少要留：

• 哪一個情境、哪個角色、哪一步發生問題。
• 當時用了什麼前置資料。
• 預期看到什麼，實際看到什麼。
• 問題屬於程式錯誤、流程規則、操作理解，還是文件說明。

UAT 回饋會重新進入開發流程，再交給指揮中心分流。程式錯誤可以進 Bug Fix；流程規則要回到 Spec 和 Plan；操作理解則可能調整欄位、按鈕或說明文件。

因此，每筆回饋要留下足夠資訊，讓開發端知道要改哪裡、走哪條路。問題只留在一句「這裡怪怪的」，是會讓人無法判斷該如何處理。

你可以先寫一張 UAT Brief

第一次找同事驗收前，可以先把一條情境整理成這張表：

# UAT Brief｜情境名稱

- 本輪要確認：
- 驗證角色：
- 前置帳號／資料：
- 操作起點：
- 主要步驟：
- 完成時應看到：
- 問題紀錄位置：
- 修正後由誰重跑：

先把一條跨角色流程寫完整，再增加其他情境。測試的人拿到這張表後，應該知道自己從哪裡開始、走到哪裡結束，以及問題要交回哪裡。

第一輪 UAT 考驗平台正確性與流程

我把能先做的工程檢查做完，整理兩輪 UAT 的 13 個情境，也安排第一輪由熟悉流程的人先進場。

DAP 的申請與單據流程開始由各科同仁與申請人實際操作。

大家應該能想像，接下來會收到很多各式使用者的回饋，處理原則是，影響系統正確性的直接修復上版，流程優化的或其他建議，則討論後安排上版。

參考資料

• ISTQB. Certified Tester Foundation Level Syllabus.