AI 時代的自動化測試與驗收（九）：測試全綠之後，如何用驗收條件、證據地圖、剩餘風險與責任分工做出交付決策？

上一篇：Playwright E2E 測試的資料隔離與可維護架構

前面幾篇把測試責任一層一層拆開：unit test 驗證規則，integration test 驗證元件接在一起後能不能運作，contract test 驗證服務之間的約定沒有漂移，E2E 則確認重要的使用者旅程真的走得完。

但就算這些測試全部通過，還是有一個問題沒有被回答：

這次交付，真的解決了使用者與業務想解決的問題嗎？

這就是驗收要處理的問題。

我把這個系列的最後一層整理成一句話：

測試確認系統照規則運作；驗收確認這次交付真的解決了問題。

驗收要把需求、可觀察證據、風險與交付決策接起來。它不等於 E2E，也不該只是 CI 最後多跑一組測試。

測試通過，不代表交付成立

自動化測試通常在回答一個已經被定義過的問題：目前的實作是否符合某個規則、契約或流程。

但產品交付還有幾個更早的問題：

• 我們定義的規則，真的是使用者需要的嗎？
• 這次實作是否涵蓋了真正重要的使用情境？
• 測試沒有失敗的部分，是否剛好是最容易被忽略的風險？
• 目前的證據，是否足以讓負責人承擔這次交付的風險？

例如，團隊要交付「使用者可以取消已付款訂單」。

測試可能只確認到：使用者可以開啟訂單頁面、按下取消按鈕，畫面最後顯示「已取消」。

功能仍可能沒有完成。驗收還要問：

• 已出貨的訂單是否不應該允許取消？
• 取消後是否建立退款流程？只改畫面上的狀態不算完成。
• 付款服務暫時無法回應時，使用者是否看得到正確的處理狀態？
• 取消動作是否留下可以追蹤的紀錄？

這些問題分別需要自動化測試、跨服務觀察，或產品與業務角色判斷。E2E 綠燈不會讓它們自動消失。

驗收條件要寫成可觀察的結果

「使用者可以取消訂單」只說明方向，還不是可判斷的驗收條件。

寫法是把使用情境、前置條件、動作與預期結果拆開：

情境	動作	可觀察結果
訂單已付款但尚未出貨	使用者提出取消	API 回傳 202 Accepted，訂單狀態變成 cancellation_pending，並產生可查詢的 refund_request_id
訂單已出貨	使用者開啟取消功能	API 回傳 409 Conflict，訂單維持 shipped，畫面說明目前狀態不允許取消
退款服務暫時無法回應	使用者提出取消	訂單維持 cancellation_pending，不會出現 refund_completed，且 next_attempt_at 有值

上面的狀態碼、狀態值與欄位是示意，重點是先在產品契約中定義通過條件；測試不能自行發明「看起來合理」的結果。

這些條件不一定要全部寫成 Gherkin，但 Given / When / Then 是一種有用的表達方式：

Feature: Cancel a paid order

  Scenario: customer cancels a paid order before shipment
    Given the order is paid and has not been shipped
    When the customer cancels the order
    Then the API responds with 202
    And the order status is "cancellation_pending"
    And the response includes a refund request ID

Cucumber 把 acceptance criteria 定義成產品要滿足、才能被使用者或利害關係人接受的條件；BDD 則把團隊對具體 examples 的討論、整理與自動化串在一起。[1] [2]

Cucumber 是否導入不是重點；驗收條件不能停在「應該可以」「流程正常」「支援取消」這類無法判斷的句子。

驗收條件至少要讓團隊知道三件事：

1. 什麼情境需要被支援？
2. 使用者或系統會做什麼？
3. 哪個結果出現時，才算這個條件成立？

Acceptance criteria 不是 test case

Acceptance criterion 是需要滿足的規則；example 是把規則放進具體情境；test case 是用某種方式執行這個 example 並檢查預期結果；acceptance review 則是把多種證據、剩餘風險與例外放在一起做接受決策。這些概念互相關聯，處理的對象卻不同。

同一個驗收條件，可能需要多種測試共同支援：

驗收條件	可能的證據
已付款且未出貨的訂單可以進入取消流程	Playwright E2E、API 狀態查詢
取消後會建立可追蹤的退款請求	integration test、事件檢查、資料庫觀察
已出貨訂單不能被取消	unit test、API test、E2E 錯誤情境
退款服務暫時失敗時，系統不會宣稱退款完成	integration test、外部服務替身、探索式測試

例如，API setup 只負責建立前置條件，驗收證據要來自真正的 assertion 或觀察結果；兩者應分開記錄。

反過來，一條測試也可能和驗收價值無關。例如，測試檢查按鈕被點擊後是否呼叫某個前端 function，可能對實作有幫助，卻不能證明使用者完成了取消訂單。

Cucumber 也特別提醒，acceptance criteria 是需要滿足的規則，不能當成測試案例清單。具體 examples 的價值，在於讓團隊更容易確認規則是否真的被理解。[3]

這個區分很重要，因為它能避免團隊把「測試數量」誤當成「驗收完整度」。

驗收不是另一層 E2E

如果把 acceptance test 直接等同於瀏覽器 E2E，通常會得到一套又慢、又難維護、又無法涵蓋所有交付判斷的測試。

Acceptance test 可以用 API、瀏覽器或人工操作，針對某個驗收條件取得證據；acceptance review 則根據整批證據、剩餘風險與例外，判斷交付是否能接受。因此，驗收流程會整合多種證據，不會只剩另一套 E2E 或人工會議。

驗收比較像一個問題，答案可以由不同層級的證據組成：

要回答的問題	適合的證據
單一規則是否正確？	unit test
元件和真實依賴接起來是否正確？	integration test
服務之間的約定是否相容？	contract test
使用者的重要旅程是否走得完？	E2E test
這次交付是否符合目標、風險是否可接受？	acceptance review、探索式測試與人工判斷

因此，驗收不一定從瀏覽器開始，也不一定以自動化結束。它可以使用 API、資料庫狀態、事件紀錄、監控訊號、使用者操作，甚至是產品負責人的明確決策。

E2E 是其中一種重要證據。它回答「完整旅程能不能走完」；驗收則要回答「這次交付是否值得接受」。前一篇已經把這兩個問題分開，這一篇把它們重新接回交付流程。

把驗收變成交付流程

驗收若等到開發完成才開始，團隊往往要到最後才發現需求不清楚、證據不足或範圍理解不同。

可行的流程是從需求討論開始建立驗收證據：

1. 先對齊問題與範圍：說清楚這次要解決誰的什麼問題，也說清楚哪些情境不在本次範圍內。
2. 列出具體 examples：用成功、拒絕、例外和恢復情境檢查團隊是否有共同理解。
3. 建立 evidence map（證據地圖）：每個驗收條件指定要靠哪一種測試、觀察或人工判斷取得證據。
4. 執行自動化與探索：讓 CI 提供可重跑的結果，再針對本次變更的未知風險做探索。
5. 留下交付決策：記錄哪些條件已滿足、哪些風險仍存在，以及誰接受了哪些例外。

這個流程要留下驗收證據，讓「完成」不只代表程式碼已經合併或 pipeline 變綠。

一個簡化的 evidence map 可以長這樣：

ID	驗收條件	主要證據	通過條件	決策責任
AC-01	未出貨的已付款訂單可以取消	Playwright E2E、訂單狀態查詢	回傳 202、狀態為 cancellation_pending，且有 refund_request_id	Product + Engineering
AC-02	取消後建立退款請求	integration test、RefundRequested 事件檢查	事件包含 refund_request_id，而且可以查詢處理狀態	Engineering
AC-03	已出貨訂單不能取消	API test、E2E 錯誤情境	回傳 409，訂單仍為 shipped	Product + Engineering
AC-04	退款服務失敗時不會誤報成功	integration test、探索式測試	沒有 refund_completed，且 next_attempt_at 有值	Product + Engineering

這張表只展示核心欄位。實際執行時，還要補上 evidence ID、實際結果、commit 或版本、environment、測試資料識別值、artifact 連結、例外與核准人。API setup 之類的資料準備則應另外記在前置條件，不要當成驗收已通過的證據。

不要把所有紅燈都叫作可接受風險

驗收決策不能把測試失敗、證據不足與已知例外混成同一件事。至少先分成三類：

• 測試失敗：先判定是產品缺陷、測試缺陷還是環境問題；必要的 quality gate 預設應該阻擋發布，不能只因為有人知道就放行。
• 證據不足：代表目前不能聲稱驗收條件成立，應該補測試、觀察或探索。
• 已知例外：如果確實要帶著風險發布，必須記錄影響、補償措施、核准人、追蹤項目，以及到期或重新檢查的條件。

已知例外不是驗收條件通過，而是有人在知道條件未完全滿足的情況下，明確批准這次發布。這個區分能避免團隊把「有留下紀錄」誤解成「任何問題都可以接受」。

AI 可以協助驗收，但不能替團隊接受風險

AI 很適合處理驗收流程中的整理工作：

• 從 user story 和規格產生候選驗收條件。
• 把驗收條件拆成成功、拒絕、例外和恢復 examples。
• 找出同一個條件目前缺少哪一層測試證據。
• 讀取測試結果、trace、log 與截圖，整理成驗收摘要。
• 根據變更內容提出探索式測試問題。

不過，把 trace、log 或截圖交給 AI 也有資料治理前提。訂單、付款與 session artifact 可能包含個資、憑證或內部拓撲；送入模型前應先遮罩敏感資料，並確認存取權限、保存期限、租戶隔離與模型使用政策。否則驗收摘要雖然變快，卻可能新增另一個資料外洩風險。

這些工作只能提供材料，最後仍由團隊接受或拒絕風險。

團隊仍然要判斷：

• 這些驗收條件是否真的描述了要解決的問題？
• AI 產生的案例是否漏掉重要的業務限制？
• 綠燈以外是否還有沒有被測到的高風險變更？
• 已知例外是否值得現在接受，還是必須先修正？
• 誰有權接受這個風險，誰需要知道這個決策？

尤其不要把「AI 說測試通過」當成獨立證據。若 AI 同時產生實作、產生測試、執行測試，再由自己摘要「已完成」，這比較像一段自我回報，不能算獨立驗證。

比較可靠的做法，是讓不同訊號各自留下證據：

• CI 執行自動化測試並保存結果。
• Playwright 的 assertions 提供可重跑、可重試的 UI 檢查。[4] 若要讓結果成為可重看的證據，還要保存 test report、trace、screenshot 等 artifact，並和版本、環境與測試資料綁定。
• 產品或測試角色針對高風險情境做探索。
• 交付負責人檢查驗收條件與剩餘風險。

AI 能加快證據整理，報告仍不能取代證據本身。

什麼應該自動化，什麼要保留人工判斷

驗收項目是否自動化，要看它的規則、變動性與判斷責任：

情境	建議方式
規則明確、結果穩定、需要反覆驗證	自動化
跨服務行為固定，但執行成本較高	自動化並保留診斷證據
需求剛形成，團隊還在探索真正要解的問題	人工討論與探索
結果涉及 UX、可理解性或業務取捨	人工判斷，必要時再沉澱成測試
風險是否值得接受取決於時程、客戶或營運情境	人工決策並留下紀錄

人工判斷不代表不需要流程。一次探索至少應該留下：

• 探索的問題或假設。
• 實際操作和觀察到的結果。
• 發現的風險、限制或未解問題。
• 這次決定接受、延期或修正的理由。

這些紀錄不一定要很長，但要足以讓下一個人知道當時看過什麼、為什麼做出這個決定。

什麼時候可以說「這次可以交付」

我會用五個問題做最後檢查：

1. 這次交付要解決的問題，是否已經用具體例子說清楚？
2. 每個重要驗收條件，是否都有對應的證據？
3. 高風險、例外與恢復情境，是否至少被探索或明確排除？
4. 測試失敗、證據不足或已知限制，是否已分類，並由正確責任人處理或正式核准例外？
5. 接受決策是否記錄了決策人、依據、例外、有效期限與重新檢視條件？

即使前四題都回答「是」，如果第五題沒有留下決策人與重新檢視條件，交付仍然可能在會議或部署之間失去脈絡。

驗收的目的不在消除所有風險。它要把剩餘風險說清楚，讓有責任的人根據足夠證據做出決定。

結語：綠燈只是證據的一部分

這個系列從第一篇對測試金字塔與信任系統的重定義開始，核心問題是：AI 讓產出變快之後，我們要怎麼知道它真的做對了？

答案要從分工開始看：Unit test、integration test、contract test 和 E2E 各自保護不同的邊界；驗收則把這些證據放回需求、使用者價值與交付風險裡，判斷這次變更是否值得接受。

驗收最重要的價值，不在多一張「通過」的標籤。它讓團隊可以回答：

我們知道這次交付改了什麼，也知道它為什麼值得被接受。

測試讓團隊敢改，驗收讓團隊知道什麼時候可以交付。AI 可以加速兩邊的工作，但信任仍然要建立在可觀察的證據與清楚的責任上。

參考資料

• [1] Cucumber，〈User story：Acceptance criteria〉
• [2] Cucumber，〈Behaviour-Driven Development〉
• [3] Cucumber，〈Better requirements by harnessing the power of examples〉
• [4] Playwright，〈Assertions〉