企業線上課程怎麼驗收？UAT、帳號、權限、報表與交付完成標準怎麼訂

企業線上課程只要牽涉多人帳號、權限、企業報表、SSO 或客製功能，最後一定會碰到一個問題：

「到底什麼時候才算做完？」

如果雙方沒有事前定義，驗收很容易變成：

• 今天發現一個錯字。
• 明天想再多一個欄位。
• 後天覺得報表最好改成另一種格式。
• 下週主管又想加一個角色。

最後開發端覺得「需求一直變」，企業端則覺得「怎麼還不能完成」。

問題通常不是誰比較難溝通，而是一開始沒有把缺陷、未完成、範圍變更分清楚。

先分清楚：UAT 不是一般技術測試

UAT 的重點不是工程師證明程式能跑，而是實際業務使用者確認：

「這套交付能不能支援我們原本要做的工作？」

Microsoft 的企業導入指南把 UAT 定義為正式上線前，由業務使用者在接近真實環境中驗證流程，最後由業務利害關係人確認與簽核。

對企業課程來說，測試者通常可以包含：

• HR／培訓窗口。
• 企業管理員。
• 一般學員。
• 必要時的 IT 或資訊窗口。

不同角色要測的事情不一樣。

驗收前先寫清楚「交付範圍」

企業課程至少可以列出：

這張表不是驗收當天才做。

最好在專案啟動就先確認，和 企業線上課程導入前怎麼開 Kickoff 的啟動範圍對齊。

驗收條件要具體，不要寫「系統正常」

「系統正常」沒有可驗證標準。

可以改成：

• 指定企業管理員可成功登入。
• 管理員只能查看自己企業的學員。
• 一般學員不能看到其他學員個資。
• 指定課程能正常開啟與播放。
• 完成一個單元後，進度能正確更新。
• 報表能匯出約定欄位。
• 停用帳號後無法再進入付費內容。

Atlassian 對驗收條件的核心觀念也是：條件要能明確判斷是否達成，而不是留下一個所有人都能用不同方式解釋的形容詞。

企業課程可以先做一份最小 UAT 情境

不需要每個案子都建立大型測試中心。

小型企業案也可以用一張表測最關鍵流程：

如果企業有 SSO、API、HR 系統或客製報表，再把這些特殊流程加入。

UAT 要用接近真實的資料與角色

Microsoft 的 UAT 建議特別強調，要在接近實際使用的環境裡，用真實業務流程與正確角色驗證。

對課程網站來說，不要全部用最高管理員測試。

因為最高權限帳號往往什麼都看得到，反而測不出：

• 學員看到了不該看的資料。
• HR 權限太大。
• 部門主管看不到應有報表。
• 停權後仍能繼續觀看。

所以至少要有：

• 一個一般學員帳號。
• 一個企業管理員帳號。
• 必要時一個已停權帳號。

驗收時要先把「缺陷」和「新需求」分開

假設原本約定：

「企業管理員可以匯出姓名、部門、完成率。」

驗收時發現「完成率欄位是空的」，這是缺陷。

但如果驗收時客戶說：

「既然有完成率，那順便再加主管姓名、員工編號、績效分數。」

這就比較像新增需求。

兩者不能放在同一張「修正清單」裡無限往下做。

可以用三類把驗收問題分清楚

例如：

• 所有學員都不能登入：阻斷性缺陷。
• 報表欄寬不好看：多半屬非阻斷問題。
• 臨時增加第三方 HR 系統串接：變更需求。

不要把「企業提出的建議」全部當成驗收失敗

UAT 本來就會產生回饋。

有些回饋非常有價值，但不代表都要在本次交付完成前做到。

可以問：

1. 這是原需求嗎？
2. 不做會不會讓原流程無法完成？
3. 這是錯誤，還是偏好？
4. 做了會不會影響既有範圍與時程？

如果答案顯示它是新功能，就應從驗收缺陷表移到變更需求。

這也是避免企業客製功能越做越多的關鍵。

「完成定義」和「功能驗收條件」要分開

軟體專案常把兩個概念分開：

• 功能驗收條件：某一個功能要做到什麼才接受。
• 完成定義：整個交付達到什麼品質才算完成。

企業課程也可以套用。

例如報表功能的驗收條件是「可正確匯出 6 個欄位」。

整體完成定義則可能包含：

• 核心流程完成測試。
• 沒有阻斷性缺陷。
• 管理員文件已提供。
• 企業窗口完成 UAT。
• 雙方確認正式上線日。

企業報表最適合直接附欄位驗收表

報表是最容易在驗收期一直追加的項目。

可以先列：

如果驗收後要再增加欄位，就可以很清楚判斷是不是客製範圍。

客製報表的邊界可以延伸看 企業客戶要求客製報表怎麼辦。

驗收不能只測「成功路徑」

至少也要測一些容易出錯的情境：

• 電子郵件（Email）地址填錯。
• 重複名單。
• 帳號已存在。
• 沒有權限的使用者嘗試看報表。
• 課程到期後重新登入。
• 企業管理員被移除後再次進入。

Microsoft 的上線檢查也建議，UAT 除了正常流程，還要測範圍內的重要例外情境與正確安全角色。

驗收環境和正式環境不要差太遠

如果測試時：

• 用的是不同登入方式。
• 沒有真實權限。
• 報表是人工做的。
• 正式上線才第一次接第三方服務。

那 UAT 通過也不代表上線會順利。

不一定要建一套昂貴的完整測試環境，但至少要讓關鍵流程、權限與整合接近正式使用方式。

誰有權簽核？不要讓所有人都有否決權

企業案可以先指定：

• 驗收窗口：統整企業回饋。
• 測試使用者：實際執行情境。
• 最終簽核者：確認是否接受交付。

如果 30 位學員都可以各自新增驗收條件，專案很難結束。

可以收集所有回饋，但是否屬於本次驗收範圍，應由指定窗口統整。

驗收紀錄至少要留下什麼？

可以保留：

• 測試日期。
• 測試角色。
• 測試情境。
• 預期結果。
• 實際結果。
• 問題類型。
• 負責人。
• 預計修正日期。
• 最後簽核結果。

不用為了形式做很厚的文件，但一定要能回答：

「當時雙方認定什麼已完成、哪些問題留待後續？」

企業說「還有一點要改」，要先問是哪一類

可以直接分流：

• 原本約定沒做到 → 修。
• 原功能有錯 → 修。
• 不影響主要流程的小問題 → 排修。
• 新的想法或功能 → 變更評估。

這種分法比一句「我們會全部配合」更健康。

企業客製案如果沒有邊界，很容易把一次性交付變成永久免費修改。

正式上線前，可以用一張 10 項清單

驗收完成後，還要定義上線後支援

驗收通過，不代表未來任何新需求都算免費修正。

最好再說清楚：

• 已知非阻斷問題何時修。
• 正式上線後問題從哪裡回報。
• 哪些算錯誤修復。
• 哪些算新需求。
• 重大問題怎麼升級。

企業客服的負責人與支援分工，可以看 企業買線上課程，誰負責開通與客服。

常見問題

企業課程一定要做正式 UAT 嗎？

不一定要做成大型 IT 專案的規模，但只要有多人帳號、客製權限、報表或整合，至少應由企業實際使用者跑過關鍵流程並留下驗收結果。

客戶在驗收時提出新需求，算原本要免費做嗎？

不一定。先對照原始範圍與驗收條件；若屬於原本未約定的新功能、欄位或整合，就應另外評估。

有小 Bug 可以先上線嗎？

要看影響。如果不會阻止核心流程，且雙方已約定修正期限，可以視情況上線；若會影響登入、權限、資料正確性或核心交付，通常不宜帶著阻斷問題上線。

UAT 應該由 IT 測還是 HR 測？

要看流程。IT 適合協助整合與技術條件，HR／企業管理員與實際學員則更適合驗證日常業務流程。重點是讓實際角色測自己的工作情境。

驗收完成一定要簽紙本嗎？

不一定。重點是留下可追溯的確認紀錄，清楚記錄驗收範圍、未解問題與正式接受結果。具體契約形式仍應依企業採購與法律需求決定。

驗收後客戶又想改報表怎麼辦？

先判斷是原報表錯誤，還是新增欄位、公式或格式。後者應進入變更流程，而不是自動視為驗收缺陷。

結論：企業驗收不是「你看一下」，而是雙方事前就知道什麼叫完成

企業線上課程越有客製化，越需要把完成標準寫清楚。

先定義帳號、課程、權限、報表與整合的驗收條件，再讓實際會使用系統的人用接近正式環境的情境完成 UAT。

驗收時把阻斷缺陷、一般缺陷與新需求分開；問題修正有明確負責人，新需求另做範圍評估，最後由指定企業窗口正式確認。

這樣驗收才會是「確認交付完成」，而不是專案最後一段無限延伸的免費需求期。

參考資料