網站驗收不能只看畫面：企業可以照做的驗收清單

一、先把交付內容變成可以判定的句子

「網站要好用」「手機版要漂亮」不容易直接驗收。可以把它改成具體任務：訪客從手機服務頁找到聯絡入口、填完必要資料、看到結果，而且公司收到同一筆詢問。這樣既能檢查畫面，也能確認流程有沒有真正完成。

開始前整理合約、確認過的設計稿與功能清單。哪些頁面包含在內、誰提供文案、商品是否已全部匯入、付款與會員功能是否屬於本次範圍，都要先對齊。若雙方對範圍有不同理解，先補成明確紀錄，不要等最後一天才把新需求和既有缺失混在一起。

驗收表不必複雜，但每列至少應有測試任務、預期結果、實際結果、證據、狀態與負責人。「按鈕可按」過於模糊；「按下聯絡後開啟正確表單，送出測試標記 A01，公司指定信箱收到」才容易判定。預期結果最好在測試前寫好，避免測完再降低標準。

二、用不同角色走過主要任務

至少區分訪客與後台管理者。訪客需要讀懂內容、找到服務、聯絡或購買；管理者則需要更新資料、查詢詢問或處理訂單。如果網站有會員，再增加會員登入與權限情境。不同角色看到的內容與能做的操作可能不同，不能只用管理員帳號測完所有事情。

選擇幾條最重要的路徑，從入口一路走到結果。例如從搜尋結果落在文章，再到服務與諮詢；或從商品分類選擇規格，完成結帳後在後台找到正確訂單。這比每頁只停留幾秒更能發現跨頁問題，也能看出資訊是否足以支持決定。

不必一開始測所有排列。先完成主要路徑，再依風險補測：手機選單、較長內容、錯誤輸入、找不到資料、重複點擊與付款失敗等。測試深度取決於網站功能與影響，不應把只有簡單展示的網站和有訂單付款的網站套成同一份清單。

三、內容與畫面要檢查到哪裡

畫面對照要使用雙方確認的版本。若設計稿與實際內容長度不同，先判斷是不是資料差異造成換行，而非只用像素差異決定錯誤。反過來，也不能以「響應式本來會變」解釋消失的文字或無法操作的按鈕。可讀性與功能完整仍然要成立。

遇到問題時，記錄網址、裝置、瀏覽器、操作步驟與預期結果。短影片適合呈現動作順序，截圖適合標示文字或位置。不要只寫「手機怪怪的」，也不需要讓使用者自行研究程式錯誤；維護者應根據回報重現並定位。

四、功能驗收要追到真正的結果

聯絡表單要測到公司實際收件，若承諾有後台紀錄，也要核對同一筆資料。只有成功提示不夠；寄信工具內的測試成功，也不能直接代替表單完整流程。若網站有預約，要確認時段、通知、取消與後台狀態的關係。

電商則要看商品選項、價格、運費、付款、訂單與通知是否一致。測試款項、退款及正式交易的授權範圍要先訂好。使用測試金流完成的訂單，應記為測試環境通過；沒有真的查到正式收款結果，就不能寫「正式收款已驗證」。

會員功能需要測試一般會員能看到自己的資料，以及未登入時哪些內容應受限制。不要使用真客戶帳號或私人資料進行破壞性測試。管理者先準備受控測試帳號與資料，再按約定範圍執行，完成後安排清理，保留必要驗收紀錄。

五、無障礙與效能都要說清楚檢查範圍

基本閱讀檢查可包含鍵盤操作、焦點是否看得見、表單標籤、錯誤回饋、文字放大與圖片替代文字。W3C 的 Easy Checks 提供入門檢查方法，同時明確指出這些項目不能代表完整無障礙評估。因此「基本檢查通過」和「符合某個無障礙標準」應分開說明。W3C 入門檢查

效能也不能只看一張分數截圖。測試工具、網路條件、頁面、裝置與時間都會影響結果。可以請廠商保留測試條件，指出發現了什麼問題與修正範圍，再實際觀察主要內容能否閱讀、按鈕能否及時操作。沒有約定的分數目標，不宜事後把單一分數當成全部驗收標準。

同樣地，自動工具沒有報錯，不等於內容沒有問題。品牌名稱寫錯、聯絡信箱接錯、詢問送到無人管理的地址，都可能需要人工核對。工具能協助找特定類型缺失，但交付判斷仍須對應網站真正用途。

六、把問題分成缺失、調整與新增需求

缺失是約定功能沒有完成或實際運作錯誤，例如應有的附件無法下載；調整可能是既有範圍內的文字、間距或呈現修改；新增需求則可能涉及原先沒有的頁面、流程或系統整合。先分類可以減少雙方誤解，但分類不能用來掩蓋已承諾而未完成的工作。

問題也應依影響安排優先度。無法送出詢問、價格算錯或會員看到不應看見的資料，和一張圖片的微小對齊差異，處理順序不相同。由雙方確認哪些項目必須在交付前修正、哪些可以在明確期限內完成，並寫下暫時使用方式及限制。

修正後不要只看廠商說「好了」。由負責者重跑原重現步驟，再檢查必要的相鄰流程。例如改了共用表單元件，其他使用同一元件的入口也可能受影響；改了純文字錯字，則不必重新測整站付款。複驗範圍要與改動關聯相稱。

七、交接資料也是驗收的一部分

網站可用之外，還要知道誰掌握網域、主機、網站管理與第三方服務。請確認帳號歸屬、續約項目、付費外掛或素材授權、備份範圍、恢復方式與日後聯絡窗口。機密內容應經適當方式交付，不放在公開操作手冊或一般驗收截圖中。

請管理者實際完成一項常見工作，例如改聯絡資料、上傳文章或查看詢問。這能確認操作手冊與目前介面相符，也能發現權限不足或流程遺漏。若管理工作由維護方代辦，則把申請方式、預期回應與不包含項目寫清楚。

最後保存一份結案狀態：已完成且驗證的範圍、仍待處理項目、各自負責人與期限，以及目前是否可以投入使用。不要讓最後一封信只剩「網站完成」，卻沒有人知道後續故障要找誰。