流程整合交付如何驗收？用正常、異常案例核對結果與限制

以需求對照、正常與異常測試、權限與資料流核驗、缺陷管理、交接文件及實際任務試跑，建立可追溯的流程整合交付驗收方法。

流程整合交付驗收的核心，是把需求變成可重現的樣本，逐一核對正常結果、失敗狀態、權限、文件與實際操作。驗收範圍應先寫明這次測過哪些情境、使用哪個版本、尚有哪些限制；通過代表約定條件有證據，不代表所有未測環境都會相同。以下以單一交付成果為主，提供可帶進驗收會議的檢查順序。

對照需求與驗收樣本

驗收要把「看起來完成」改成一條可追溯的判斷：哪項需求、用哪份樣本、看到什麼結果才算通過。先把每條需求拆成輸入、處理、輸出、負責角色與例外，避免用「自動化正常」「畫面可用」這類無法裁決的句子。假設表單送出後要建立一筆客戶資料，可分別列出欄位對應正確、資料只建立一次、指定負責人收到通知、來源標籤保留四項條件；每項都附測試資料和可讀證據。若需求寫「速度要快」，先約定從送出到哪個狀態、在哪種網路或資料量下計時，以及容許範圍；沒談定就列為待確認，不能在驗收當天臨時憑印象放行。 驗收表可用一列一條件，記錄需求編號、前置狀態、輸入樣本、預期結果、證據位置、判定人與通過狀態。先挑典型資料，再挑會碰到邊界的資料；例如選填欄位為空時，預期是略過、填入預設值，還是轉人工處理，必須事先寫清楚。測試資料集和交付版本也要標記版本，修正後沿用同一批樣本重跑，並保留曾失敗的樣本，避免換成較容易通過的資料而誤以為缺陷消失。需求尚未有負責人、預期值或判定方式時，將該列標成未定，不把它折算成通過率。這份對照表就是會議共同依據，讓提出需求的人能指出缺口，執行者能重現，簽收者也能說明接受的是哪個範圍。樣本也要對應不同來源、角色和資料狀態，不能只挑建置者熟悉的一筆。由需求方確認必填欄位、允許轉換與簽收角色；若工作時段、資料量或來源格式會改變流程，也把它列成條件。通過標準優先寫可觀察動詞，例如「建立一筆且識別值一致」，少用仍需解讀的「正確處理」。

測試正常和異常路徑

正常路徑證明資料能到達預期終點，異常路徑則確認出錯時不會悄悄產生錯誤資料。把每種情境寫成「前置條件、操作、預期狀態、證據」，至少涵蓋成功提交、必要欄位缺漏、格式不合、重複提交、下游暫時無回應，以及人工取消。測試時先確認起始資料乾淨，再執行一次，不要只看畫面上的成功提示；同時核對來源端、目的端、通知或待辦狀態，確認資料數量、欄位值和處理時間彼此一致。若系統有重試，需觀察重試後是否重複建立紀錄；若沒有自動重試，也要看到任務停在哪裡、由誰接手。 以下是明確假設的表單到客戶資料與通知流程，不代表任何客戶案例或固定系統能力： | 測試情境 | 預期結果 | 判定重點 | |---|---|---| | 資料完整並提交一次 | 建立一筆資料並通知負責人 | 欄位、筆數與通知對象相符 | | 再送出相同識別值 | 不新增重複資料，或依約提示人工確認 | 有可查的重複處理結果 | | 缺少必要欄位 | 停止寫入並指出待補資料 | 不能留下半筆正常紀錄 | | 目的系統暫時無回應 | 保留待處理狀態並可由負責人追蹤 | 不顯示假成功、不遺失原始輸入 | 執行記錄要包含樣本代號、實際結果和時間，不要貼入不必要的個資或憑證。遇到錯誤先保留現場再重跑，否則重試可能改變狀態，讓人分不清原故障和補救動作。特別處理部分成功：例如目的端已寫入，但回應逾時，操作人不知道是否安全重送。驗收要先定義用哪個識別值查找既有紀錄、如何判斷待重試，並驗證重送後只得到一筆結果。通知延遲時也要確認資料本身沒有被反覆建立，讓「通知未到」和「寫入失敗」不會被混為一談。

核驗權限與資料流

資料流核驗要沿著實際路徑逐站看：誰產生資料、經過哪些轉換、寫到哪裡、誰收到通知，以及失敗時落在哪個可追蹤狀態。先以欄位對照表檢查名稱、格式、空值規則、時區或識別值是否一致；再用一筆不敏感的測試資料逐站核對，記錄來源值、轉換後值和目的端結果。只看單一畫面會漏掉映射錯位，例如姓名正確但電話被寫進備註欄；所以要確認關鍵欄位、筆數與關聯識別值，而非只截取「成功」訊息。 權限也要納入同一條路徑。列出觸發流程的帳號、讀取與寫入範圍、查看紀錄的人，以及能重試或停用的人；用不具權限的測試角色確認它確實無法讀取或改寫不應處理的資料。測試帳號不應共用個人密碼，交接文件也只寫憑證存放位置和輪替負責人，不複製密鑰或存取權杖。若流程需要人工覆核，確認待辦只交給約定角色，拒絕操作後不會繞過核准繼續往下走。 最後檢查紀錄是否足以定位故障，又不把敏感內容散落在截圖或訊息裡。保留事件時間、樣本代號、狀態變化和錯誤類型；若要提供畫面證據，遮蔽姓名、聯絡方式及憑證。資料保留、刪除和備份方式若未在需求中約定，應列成限制或待決事項，不自行推定適用規則。跨多個目的地時，可用同一個樣本代號逐站對照筆數，確認一處成功不會被誤當全流程完成。人工修正後還要回看下游是否收到更新，以及舊值有無殘留；若有排程或佇列，記錄等待狀態和負責檢查的角色。不要把畫面截圖當成完整資料證明，必要時用遮罩後的欄位摘要和狀態時間線核對。

記錄缺陷和限制

缺陷紀錄要讓另一位執行者能重現，並讓決策者看懂它對工作造成的影響。每筆至少寫樣本代號、前置狀態、操作步驟、預期與實際結果、發生頻率、證據位置、暫時處理方式、負責人和下一個判斷時間。不要只留「通知錯了」；要指出通知送給誰、使用哪筆測試資料、實際收到什麼、在哪個狀態出現。修復後用原步驟重跑，再跑一次相關正常路徑，確認補救沒有讓其他情境失效。 分類時分清缺陷、限制和未決需求。缺陷是已承諾條件未達成；限制是某些資料、角色、時段或故障情況不在本次交付範圍，但需說明影響和替代做法；未決需求則是雙方尚未選定規則，不能直接當成系統錯誤或默認接受。判斷嚴重度可看是否阻斷主要任務、是否造成重複或錯誤寫入、是否能人工補救，以及補救成本由誰承擔。凡會漏資料、越權或誤寫關鍵欄位的問題，先停止相關路徑並指定處理人；低影響問題也要留下期限或明確接受條件。 簽收紀錄應把通過範圍和未完成項分開，附上接受者、版本、樣本集、未解缺陷、暫行操作與停止條件。若接受者決定帶著已知限制使用，寫明哪些任務仍須人工檢查、何時重新評估、出現什麼狀況就停用。不要把「大致可用」寫成零缺陷，也不要把局部樣本通過擴大成永不故障、全面安全或效益保證。清楚的限制表讓團隊在日常使用中知道何時自行處理、何時回報，以及誰有權決定繼續或暫停。若缺陷在重跑時偶發，記下總嘗試次數、成功與失敗各幾次，避免單次成功掩蓋間歇性故障；無法重現也應保留原始證據和目前判定。

清點交接文件

交接文件的目標是讓接手者能理解、操作、判斷失敗並安全求助，不是把一疊檔案交出去就算完成。先清點需求與驗收表、流程圖、欄位映射、測試樣本說明、通過與未通過記錄、缺陷清單、權限角色、操作步驟和變更版本。每份文件標示適用環境、更新日期、維護責任人和關聯版本；圖上的每個步驟最好能對回實際系統或人工動作。若圖與現況不一致，以現況為準重畫或標註差異，不能要求接手者猜哪份是最新。 操作說明應以工作任務編排：如何查看待處理項目、如何辨認成功與等待狀態、如何補正輸入、何時可安全重試、何時須停止並通知負責人。特別寫明重試可能造成的副作用，以及重複資料如何辨識；若只有管理者能回復，就註明角色和交接方式。設定清單可列觸發條件、欄位映射、通知對象、例外分支和停用方法，但不得把密碼、權杖、私人客戶資料放進一般文件。憑證應由有權管理的人透過組織採用的安全管道交接，並確認新負責人能以自己的權限完成必要操作。 最後安排接手者照文件獨立走一次指定任務，記下在哪一步需要口頭提示；需要提示的段落就是文件缺口，補上後再試。確認日常負責人、備援聯絡人、問題回報管道和維護邊界都有人名或角色可對應。若環境、帳號或上游欄位變更，誰負責更新映射、重新驗收哪些樣本，也要寫清楚。文件應提供足夠資訊重現結果，同時只暴露完成工作所需的資料；清點完成不是終點，接手者真的能依文件操作才是交接完成。將檔名或版本號與驗收單一致，避免不同文件版本互相矛盾。

試跑實際使用任務

最後不要只在簡報或測試環境看演示，應由未參與建置的實際使用者，按日常方式完成一項端到端任務。先選低風險、可追回的工作，約定起始資料、允許操作、預期產出、觀察人和停止條件；全程記錄人在哪些地方要判斷、等待或補資料。若流程會通知真實對象、改動正式紀錄或觸發付款等不可逆動作，先改用測試對象或隔離資料，確認副作用被控制後才討論正式試跑。試跑不是要求使用者替系統找所有錯，而是看交付能否在真實工作節奏裡被理解和接手。 明確假設一次試跑包含十二筆練習資料：八筆完整資料、兩筆相同識別值、一筆缺少必要欄位、一筆目的端暫時無回應。預先約定八筆完整資料各建立一次；兩筆重複資料不得靜默新增；缺欄資料須停止並提示補件；暫時無回應的資料須保留可追蹤狀態。結果逐筆對照後，若其中一筆完整資料沒有建立，就不能用其餘十一筆掩蓋失敗；若都符合，也只能說這組指定樣本和當時設定通過，不能推論所有未測資料都沒問題。記下任務用時、人工介入點和理解困難，這些觀察用來決定是否補文件、調整規則或擴大下一批樣本，不等於效益保證。 試跑結束後，請使用者用自己的話說明如何辨認待處理狀態、如何回報錯誤、何時不得重試；若說不清，先修正交接再簽收。簽收前由需求負責人逐項確認通過條件、限制、未修項目、維護責任和暫停方式，並留下版本與日期。下一步可先挑一條最常卡住的工作流程，寫出輸入、預期結果、例外處理和負責人，再帶著這張驗收單開始討論：ZhenheAI 官方網站。