Shopify 網站能打開、首頁看起來正確，也可能還不能上線。價格可能在某個市場顯示錯誤，付款成功後 ERP 沒收到訂單，舊網址回傳 404，或 purchase 事件被送了兩次。驗收的工作，是用預先約定的案例證明交易、資料與營運能一起運作。
開始測試前先確認版本、環境、測試帳號和已知限制。口頭說「這裡之後會修」不方便追蹤，所有結果都應回到同一套案例與問題清單。
用旅程建立測試案例
從主要顧客類型出發，列出瀏覽、搜尋、選擇變體、加入購物車、套用折扣、付款、通知、出貨、取消與退款。每個案例要有前置資料、操作步驟、預期結果和證據。正常流程之外，也要測缺貨、付款失敗、地址錯誤、優惠不適用和重複送出。
若有 B2B、訂閱、多市場或門市取貨，分別建立旅程。不要用一張「結帳 OK」同時代表所有價格、權限和履約情境。
商品與會員要做數量和抽樣
資料驗收先比總數，再依高風險類型抽樣。商品檢查 SKU、變體、價格、比較價、庫存、重量、圖片、分類和 metafield；會員則檢查 email、姓名、地址、標籤、同意狀態與權益。來源資料本來就缺少的欄位，應在遷移前記錄，不能在驗收時才爭論。
抽樣要包含一般商品、變體最多的商品、缺貨品、特殊稅率或運送限制，以及最近和最舊資料。詳細盤點方式可沿用 Shopify 遷移清單。
金物流要跑真實端到端流程
測試模式能快速覆蓋錯誤，但正式金流仍應以可控的小額訂單驗證。確認付款狀態、幣別、手續費、退款、訂單通知、發票、物流標籤、庫存扣減和外部系統回寫。若有超商取貨或貨到付款，也要走完實際選店與訂單處理。
測完後留下 Shopify 訂單編號、金流交易號、ERP 或 WMS 紀錄和時間戳。單一系統顯示成功，不代表整條流程完成。
SEO 驗收看可抓取的結果
檢查 title、description、canonical、robots、sitemap、結構化資料與主要內部連結。遷移專案還要用完整舊網址清單測試永久轉址，避免所有網址都導向首頁。Google 的 網站搬遷指南可作為切換與監控依據。
用 crawler 和 HTTP 回應檢查實際輸出，不要只看後台欄位已填寫。JavaScript 畫面正常，也可能有錯誤 canonical 或無法抓取的連結。
分析事件要和訂單對帳
確認 view_item、add_to_cart、begin_checkout、purchase 等事件的名稱、參數、幣別和價值。重整完成頁、返回上一頁或付款失敗時，不能重複計算購買。廣告 Pixel、server-side event 與 GA4 若同時使用，要驗證去重方式。
用幾筆測試訂單對照 Shopify、GA4、廣告平台和資料倉庫。不同系統因歸因與處理時間不會完全相同，但事件缺漏、重複與幣別錯誤應在上線前處理。
效能與無障礙要測真實頁面
效能至少涵蓋首頁、集合、商品與內容較重的頁面，分別在行動裝置與桌面觀察。實驗室工具用來找問題，上線後仍需追蹤真實使用者資料。不要只挑最輕的頁面截一張高分報告。
無障礙驗收包含鍵盤操作、焦點、表單標籤、錯誤提示、替代文字、對比和縮放。自動工具能找到部分問題，關鍵交易仍要人工走一次鍵盤與讀屏流程。
最後驗收的是營運能力
請實際負責的人完成商品更新、活動發布、訂單處理、退款、會員查詢和權限管理。交付程式碼、設計檔、帳號、架構、發布、整合與事故文件，並確認品牌具有需要的管理權限。
缺陷要依商業風險分級
阻斷付款、價格錯誤、個資暴露和訂單遺失屬於上線阻擋；特定裝置無法操作關鍵流程通常也應先修正。文字錯字或低流量頁面的輕微間距，可以記錄 owner 與期限後排入下一批。分級規則要在 QA 前約定，不能到上線會議才為每一張 ticket 爭論。
每次修正都要回到原案例重測，也檢查相鄰流程是否受影響。關閉問題時附上版本、環境與證據；只在訊息中回覆「fixed」，日後無法確認正式站是否包含同一變更。
上線會議應用明確條件判斷 go、延後或降階，包含仍開放的高風險問題、資料差異、付款結果和回復方案。把 專案需求書中的每個目標連回測試證據，才能讓「驗收完成」成為可重現的結論，而不是會議裡的一句感覺。