企業線上課程做到最後，最容易出現的一句話是：
「我們再看一下，還有幾個地方想調。」
如果前面沒有驗收標準，這句話可能一路延伸成：
- 再多一個部門權限。
- 再加一個報表欄位。
- 再改一次登入流程。
- 再多一種通知方式。
- 再串另一套系統。
最後專案一直沒辦法順利結束。
所以企業課程的驗收，不是到尾聲才問「客戶滿不滿意」，而是從一開始就要定義：
「做到哪些條件，就算完成這一階段的交付？」
先分清楚：UAT 不是功能測試的最後一輪
使用者驗收測試（UAT）主要是由實際業務使用者確認：
- 這套系統能不能支援真實工作流程。
- 角色與權限是否符合實際使用情境。
- 重要資料是否正確。
- 整體操作能不能完成原本承諾的工作。
它和工程團隊自己做的功能測試不同。
工程測試回答：
「這個功能有沒有照規格運作？」
UAT 更接近：
「這套東西放進企業現場，使用者能不能完成工作？」
Microsoft 的實作指南也把 UAT 放在正式上線前，要求由實際業務角色使用接近真實情境的資料與流程測試，最後由企業端簽收。
第一步：驗收範圍要在測試開始前鎖定
如果驗收期間還一直新增新功能，測試永遠沒有終點。
因此要先列清楚本次驗收範圍。
例如：
- 企業管理員可以新增、停用與查看成員。
- 學員可以登入指定課程。
- 不同角色只能看到自己應有的內容。
- 完成率與指定報表欄位正確。
- 課程通知能正常寄送。
- 付款或企業授權狀態能正確控制權限。
同時也應列出：
本次不驗收、也不包含的項目。
例如：
- 尚未購買的 SSO。
- 下一階段才做的 API 串接。
- 額外客製 Dashboard。
- 新的企業專屬功能。
把「不包含」寫出來，可以降低驗收階段出現範圍膨脹。
第二步：先定義「誰來驗」，不要只讓採購或業務看畫面
應該參與驗收的人，是未來會實際使用系統的角色。
| 角色 | 驗收重點 |
|---|---|
| 企業 HR／培訓窗口 | 名單、席次、報表、通知 |
| 部門主管 | 完成率、部門資料、學習進度 |
| 一般學員 | 登入、上課、作業、證書 |
| 企業 IT | 登入整合、網路、權限、安全 |
| 課程管理員 | 開通、停權、異動、客服流程 |
如果只讓專案窗口自己點一輪，很容易漏掉實際使用時才會遇到的問題。
第三步：測試案例不要寫成「請自由測試」
UAT 最怕一句：
「你們有空進去玩玩看，有問題再跟我說。」
這種測試通常最後只會收到一些零散意見。
比較好的做法，是把重要流程寫成情境。
例如：
案例 1｜新學員開通
- HR 提供新學員資料。
- 系統建立帳號。
- 學員收到登入通知。
- 學員第一次登入。
- 看得到正確課程。
案例 2｜員工離職
- HR 提出停權。
- 系統管理員停用帳號。
- 該學員不能再進入企業課程。
- 企業歷史報表仍依原規則保留。
案例 3｜部門主管查看進度
- 主管登入管理頁。
- 只能看到自己有權限的部門。
- 完成率與名單正確。
- 不能看到其他部門不應公開的資料。
案例越接近真實工作，驗收價值越高。
第四步：每個案例都要有「預期結果」
不要只寫：
「測試學員登入。」
要寫成：
| 測試項目 | 預期結果 |
|---|---|
| 有效帳號登入 | 成功登入並看到正確課程 |
| 未授權帳號登入 | 不能看到企業付費內容 |
| 主管查看報表 | 只看到授權範圍資料 |
| 員工離職停權 | 停權後無法繼續進入課程 |
| 證書產生 | 符合完成條件後才能取得 |
預期結果越明確，驗收時越不會陷入「我覺得這樣不太對」的模糊討論。
第五步：帳號驗收，不只看「能登入」
至少要測：
- 新帳號建立。
- 首次登入。
- 忘記密碼。
- 帳號停用。
- 企業成員新增與移除。
- 席次超額時的處理。
如果企業有單一登入（SSO），還需要測：
- 正常登入。
- 公司帳號停用後能否進入。
- 角色同步是否正確。
- 錯誤登入的提示。
企業 SSO 是否值得做，可以搭配 企業課程需要單一登入 SSO 嗎？帳號安全、IT 串接與導入成本怎麼評估。
第六步：權限驗收一定要用不同角色實際測
權限不能只看後台設定表。
應該真的用：
- 一般學員。
- 部門主管。
- 企業管理員。
- 系統管理員。
分別登入。
確認：
- 能看到什麼。
- 不能看到什麼。
- 能不能下載。
- 能不能修改。
- 能不能匯出。
企業最怕的不是某個按鈕不好看，而是 A 部門看到了 B 部門的個資，或一般學員拿到管理權限。
第七步：報表驗收要先對「數字定義」
企業說「完成率」，雙方可能不是同一個意思。
所以要先確認：
- 開始學習怎麼算。
- 完成怎麼算。
- 作業是否影響完成。
- 測驗門檻是多少。
- 停權員工還算不算分母。
- 日期範圍怎麼切。
報表驗收不能只看版面，還要抽幾位真實測試帳號手算，比對結果。
如果有企業專屬欄位與公式，可以看 企業客戶要求客製報表怎麼辦？標準報表、加價客製與資料欄位邊界怎麼訂。
第八步：通知信也要驗收，因為很多問題出在「系統有做，但人沒收到」
可以測：
- 開通信。
- 密碼重設信。
- 課程提醒。
- 直播通知。
- 完成通知。
並確認：
- 寄件人名稱。
- 主旨。
- 收件人。
- 連結是否正確。
- 企業信箱是否會擋信。
功能本身成功，不代表整個使用流程成功。
第九步：整合驗收要測「完整流程」，不是只測 API 回 200
如果企業有：
- SSO。
- HR 系統。
- LMS。
- API。
- 外部報表。
整合驗收應該從真實操作開始。
例如：
HR 新增一位員工 → 帳號同步 → 課程指派 → 員工登入 → 完成課程 → 完成結果回到企業系統。
只測某一支 API 是否回傳成功，還不能證明整條流程可以交付。
企業 API 與資料串接的邊界，可以看 企業版線上課程要不要提供 API 或資料串接？LMS、HR 系統、報表與維護邊界。
第十步：Bug、設定問題、新需求一定要分開
這是驗收能不能收尾的關鍵。
| 類型 | 例子 | 處理 |
|---|---|---|
| Bug | 原規格應能登入，但現在登入失敗 | 修正後重新測試 |
| 設定問題 | 企業名稱或通知時間設定錯誤 | 調整設定 |
| 原規格缺漏 | 雙方原本明確約定但尚未完成 | 補完再驗收 |
| 新需求 | 驗收時才提出新增 Dashboard | 另案評估 |
新需求不是不能做。
但如果它原本不在本次交付範圍，就不應該被寫成：
「你們沒做這個，所以我們不能驗收。」
第十一步：建立缺陷嚴重度，不要所有問題都阻擋上線
可以簡單分成：
P0｜阻擋上線
例如：
- 全體無法登入。
- 權限錯誤造成資料外洩風險。
- 核心流程完全不能用。
P1｜高優先修正
主要流程受影響，但有暫時替代方式。
P2｜可排後續
不影響核心交付的文字、版面、小型體驗問題。
這樣才能避免一個按鈕顏色，也和帳號權限錯誤被當成同等級。
測試資料要足以驗證流程，但不要不必要地複製大量正式個資
UAT 要接近真實情境，不代表一定要把整份正式員工名單、真實作業與敏感資料全部搬進測試環境。能用測試帳號、假資料或經挑選的少量測試資料完成驗證時，就不需要擴大資料暴露範圍。
若某些整合一定要用真實企業帳號測試，也應限制測試人數、權限與保存期間，並在驗收結束後清理不再需要的測試資料。
第十二步：驗收不能只看「正常情況」，還要測幾個例外
例如：
- 重複電子郵件（Email）。
- 名單少一欄。
- 員工已存在。
- 席次已滿。
- 課程已到期。
- 企業管理員被停權。
- 報表沒有資料。
正式上線後，使用者不會只走完美路徑。
UAT 要先約定回覆期限與單一意見窗口
如果企業有五個部門都能直接留言，驗收很容易變成同一個畫面收到五套互相衝突的意見。比較穩定的做法，是由企業指定一位驗收窗口彙整意見，再以同一份缺陷清單回覆。
同時也要先排出驗收期間，例如哪一天提供測試版、企業預計幾個工作天內完成第一輪、修正後幾天內複測。若企業長時間未回覆，不要自行假設「沉默就是驗收通過」；如果雙方需要逾期處理機制，應在報價或合約階段事前約定。
把時間與窗口定清楚，才能區分「系統還沒完成」和「企業內部還沒完成驗收」。
第十三步：UAT 開始後，不要邊測邊改大範圍
Microsoft 的 UAT 指南也明確建議，當測試案例、版本與範圍確認後，不要在 UAT 中途再引入新的使用者體驗或大幅改動。
原因很簡單：
你一邊測、一邊改，前面通過的結果可能立刻失效。
如果真的有重大變更，就應該：
- 記錄變更。
- 確認是否影響驗收範圍。
- 更新版本。
- 重新跑受影響測試案例。
第十四步：驗收通過要有一個正式「簽收點」
不要讓專案永遠停在：
「我們內部還在看看。」
驗收完成可以有一張簡單簽收表：
- 驗收版本。
- 驗收日期。
- 測試案例。
- 未解決問題清單。
- 哪些問題允許上線後處理。
- 企業簽收人。
- 課程方簽收人。
簽收不代表未來永遠不能改。
它代表：
「這一階段按照雙方約定的範圍，已經完成。」
驗收完成後，新需求就進下一階段，不要回頭改掉完成定義
這也是企業案最需要守住的範圍邊界。
例如客戶驗收後才說：
「我們主管又想到，能不能再加一個跨部門報表？」
可以評估。
但它應該是：
- 下一期改善。
- 新功能。
- 客製加購。
- 後續維護。
而不是重新把上一階段變成「尚未完成」。
一張企業課程 UAT 驗收表，可以包含這些欄位
| 欄位 | 內容 |
|---|---|
| 測試編號 | UAT-001、UAT-002 |
| 角色 | HR／主管／學員／IT |
| 情境 | 要完成的實際工作 |
| 前置條件 | 帳號、資料、權限 |
| 操作步驟 | 實際測試流程 |
| 預期結果 | 什麼叫通過 |
| 實際結果 | Pass／Fail |
| 嚴重度 | P0／P1／P2 |
| 負責人 | 誰修、誰複測 |
| 結案狀態 | 已修正／接受／另案 |
常見問題
UAT 一定要由企業自己測嗎？
最終驗收最好由實際業務角色參與，因為他們才能判斷流程是否符合真實工作需求。課程方可以準備案例、帳號與測試資料，但不應自己測完就替企業簽收。
客戶驗收時提出新需求，一定要免費做嗎？
不一定。先判斷它是不是原本已約定但漏做；如果是驗收階段才新增的需求，就應另外估範圍、成本與時程。
有小問題還可以驗收通過嗎？
可以。只要雙方清楚列出未解決項目、風險、負責人與完成期限，且它不影響核心使用或安全，就可以設定「條件式通過」。
企業只想自己隨便點一點，可以嗎？
不建議。沒有情境與預期結果，最後很難證明哪些流程測過、哪些沒測，也容易把偏好建議和實際缺陷混在一起。
報表驗收最容易漏什麼？
最容易漏的是數字定義與權限。除了看畫面，要抽樣比對真實帳號，確認完成率、日期範圍與角色可見資料都符合約定。
UAT 完成後還要測嗎？
正式上線後仍需要監控與必要的回歸測試。UAT 代表這一版已被業務接受，不代表未來更新不需要再驗證。
結論：企業驗收不是「挑到沒有意見」，而是確認約定範圍已能支援真實工作
企業線上課程的驗收要能收尾，關鍵不是做更多功能，而是提前定義完成標準。
先鎖定範圍、角色、測試案例與預期結果，再測帳號、權限、報表、通知與整合；發現問題後，把 Bug、設定問題、原規格缺漏與新需求分開處理。
當核心流程通過、重大風險已處理，而且企業端正式簽收，這一階段就應該結案。
之後有新的想法，可以繼續做，但應該進入下一個範圍，而不是讓「驗收」變成沒有終點的加功能清單。
參考資料：
Microsoft Learn｜Guide for User Acceptance Test after Data Migration。
Microsoft Learn｜Types of tests that implementation projects use。
Microsoft Learn｜Create a test plan for your implementation projects。
Microsoft Learn｜Use the go-live checklist to make sure your solution is ready。
ISTQB Glossary｜Acceptance Criteria、Acceptance Testing。