軟體驗收怎麼做：UAT 測試、缺陷分級與付款節點
專案做到最後，最容易吵起來的一句話是：「這樣算不算做完？」
廠商說功能都做了，業主說用起來根本不對。問題通常不是誰偷懶，而是雙方從頭到尾沒有一份共同認定的「完成」定義。驗收要順利，關鍵不在最後那兩週怎麼測，而在專案開始時有沒有把標準寫下來。
驗收標準不是驗收時才想，是從需求長出來的
驗收標準（Acceptance Criteria，白話說就是「怎樣才算做對」）應該在需求階段就成形。做法很單純：把需求文件裡每一條功能描述，改寫成一句可以判斷真假的句子。
- 需求寫「會員可以修改個人資料」→ 驗收標準是「登入後進入會員中心，修改姓名與手機並儲存，重新登入後顯示為新資料」
- 需求寫「後台可以匯出訂單」→ 驗收標準是「選定日期區間匯出後，檔案可用試算表開啟，欄位包含訂單編號、金額、狀態、成立時間」
差別在於前者無法判斷對錯，後者可以。如果需求文件還停留在前者，先補這一步，寫法可參考軟體需求怎麼寫。
還有三類標準常被漏掉，卻是爭議最多的地方：
非功能標準：頁面載入速度、同時上線人數、要支援的瀏覽器與手機型號範圍。這些若沒寫進驗收，上線後才抱怨「很慢」是沒有依據的，量測方式可看網站速度優化指南。
資料標準：舊資料要不要搬、搬哪些、搬過去之後怎麼驗證筆數與內容正確。
權限標準：每一種角色看得到什麼、不能做什麼。權限是最常在驗收階段才被發現做錯的部分。
測試案例怎麼列（非工程師版）
測試案例就是一張「照著做、對答案」的清單。每一列至少要有四欄：
| 欄位 | 內容 |
|---|---|
| 情境 | 在什麼身分、什麼狀態下操作 |
| 步驟 | 具體的點擊與輸入順序 |
| 預期結果 | 應該看到什麼 |
| 實際結果 | 測的人填寫，不符就記為缺陷 |
除了「一切正常」的順流程，務必補上這三種：
異常輸入：空白、超長字串、特殊符號、格式錯誤的手機或統一編號。
邊界情況：數量填到上限、庫存剛好為零、優惠剛好到期、名額剛好額滿。
權限越界：用低權限帳號直接輸入高權限頁面的網址，看系統擋不擋。
實務上普遍觀察到，順流程幾乎都會過，真正抓得出問題的是後面這三類。
誰來測：三種角色，缺一不可
開發方的內部測試：功能完成就該做，不該把明顯的錯誤丟給業主當第一位使用者。
業主端的使用者驗收測試（UAT）：由實際要用這套系統的同事測。真正的行政、客服、業務人員，才測得出流程不合理的地方。
旁觀者測試：找一位完全沒參與專案的同事，不給教學，看他能不能自己完成主要任務。這是最省成本也最誠實的易用性檢查。
建議指定一位驗收窗口彙整所有回饋，統一回報。多人各自直接傳訊息給工程師，是驗收拖延最常見的原因。
缺陷分級：不是所有問題都該擋上線
把所有回饋丟成一包「還有問題」，只會讓雙方互相消耗。實務上至少分成四級：
- 阻斷級：核心流程走不完，例如無法下單、無法登入、資料存不進去。必須修完才能上線。
- 嚴重級：功能可用但結果錯誤，例如金額計算不符、通知寄錯對象。上線前必修。
- 一般級：不影響結果的操作不順或顯示不一致。可排在保固期處理。
- 輕微級：文字錯字、間距不齊。累積後一次修。
另外要區分「缺陷」與「新需求」。缺陷是做出來的和講好的不一樣，新需求是講好的內容本身要改。後者屬於變更，應該另外評估工時與時程，而不是包在驗收裡免費做完。這條界線若在合約裡沒寫清楚，驗收就會變成拉鋸，相關條款可參考如何挑選軟體開發公司。
驗收與付款節點怎麼綁
付款節點的意義，是讓雙方在每個階段都有把事情做對的動機。常見的綁法，是把款項拆在需求與設計確認、開發中期、驗收通過、保固期滿等節點上，每個節點對應明確的交付物。
有幾個原則值得堅持：
- 每個節點都要有可驗證的交付物，而不是「進度差不多了」這種說法
- 驗收要有明確的回覆期限，業主逾期未回覆的處理方式也要先寫清楚
- 尾款不宜全部壓到最後一刻才付，也不宜在驗收之前就付清
NETVANA 的開發階段以兩週為一個 Sprint，每個週期結束提供可操作的 Demo，用意就是讓問題在過程中被看見，而不是堆到最後一次爆發；完整階段說明見軟體開發流程。
上線不是終點：保固期涵蓋什麼
驗收通過之後通常會有一段保固期。合約要寫清楚三件事：
涵蓋範圍：保固修的是與驗收標準不符的缺陷，不含新增功能，也不含因你方自行修改或第三方服務變更造成的問題。
回應與修復的分級：阻斷級問題的處理方式，和輕微問題不應該一樣。
保固結束後怎麼辦：轉入維護合約，或改為按次計費。這部分的常見型態與爭議，可以看網站維護費用包含什麼。
如果系統有串接外部服務，還要特別確認：對方系統改版導致的失效算不算保固範圍。這類邊界建議在整合開始前就談定，背景可參考系統整合與 API 串接開發指南。
驗收開始前，先確認這幾件事
驗收之所以拖，很多時候不是問題太多，而是根本還沒準備好就開始測。開始之前，雙方先確認以下幾項，能省下大量往返：
測試環境是否獨立。驗收應該在一個和正式環境設定相同、但資料可以隨便玩的環境進行。直接在正式環境測，會出現測試訂單、測試簡訊發給真實客戶這類麻煩。
測試資料是否齊備。要驗證會員分級，就要先有各種等級的測試帳號；要驗證訂單流程，就要有可用的測試金流資訊。這些若沒先準備，測試會在第一步就卡住。
測試期間多長、誰有空。驗收需要實際使用者投入時間。如果同事們手上都是滿的，驗收就只會變成「打開看一眼，看起來還好」，問題全部留到上線後。時間要事先排進行事曆。
回報管道統一。用同一份文件或同一個追蹤工具，每一筆問題有編號、狀態與負責人。散落在不同對話框裡的回報，最後一定會漏。
驗收通過的定義先講好。是「阻斷級與嚴重級全部修完」就算通過，還是要全部零缺陷？後者實務上不存在，堅持它只會讓專案永遠無法結案。
三個最常見的驗收爭議，以及怎麼避免
爭議一：「這跟我想像的不一樣」 多半出在設計確認階段太快帶過。避免方式是在開發前就用可點擊的原型確認流程，而不是等到成品做出來才第一次看到。
爭議二：「這個功能當初有講」 口頭討論沒有留下紀錄，就會變成各說各話。所有討論結論都應回寫進需求文件或會議紀錄，並請雙方確認。
爭議三：「效能不符預期」 「很慢」不是可驗收的描述。應該在需求階段就約定量測條件與工具，例如在哪一種網路環境、量測哪些頁面、用什麼工具判讀。
這三類爭議有一個共同點：都不是在驗收階段產生的，而是在更早的階段留下的。這也是為什麼廠商評估時，該問的不只是報價，還包括他們怎麼處理需求確認與變更。
驗收做得好不好，其實在專案第一週就決定了。需求寫得能判斷真假、標準雙方都認、缺陷分級事先講好，最後那段就會是確認，而不是角力。
如果你手上的專案正要進入驗收、或想在開案前先把驗收條款談清楚，與 NETVANA 討論你的專案，我們會先釐清範圍與交付標準再談後續。
延伸閱讀：需求文件怎麼寫成可驗收的形式，看軟體需求怎麼寫；想知道專案為什麼容易拖延，看軟體專案為什麼總是延誤；上線後累積的技術品質問題怎麼談，看技術債是什麼；第一版要驗收什麼，取決於範圍怎麼切，可以看MVP 最小可行產品開發指南；驗收通過之後，還有送審這一關要過，可以看App 上架完整檢查清單；驗收前先搞懂廠商說的各種測試到底在測什麼，可以看自動化測試白話解釋與驗收；驗收分清缺陷等級後，回報問題時也該這樣分，可以看怎麼跟開發廠商回報問題；部署前的測試環境正是驗收該發生的地方，可以看測試環境、正式環境與部署白話指南。
