自動化測試跑到最後一個 Step。

畫面先出現：

Command completed successfully
Exit code: 0

幾秒後，整個 Case 卻變成紅色。

Verification failed
Expected: feature enabled
Actual: feature disabled

有人第一眼以為 Framework 判斷錯了。

「Command 都成功了，為什麼還 Fail？」

另一個人反過來問：

「如果 Test Case Pass，那我們到底是在驗證 Command 有沒有送出去，還是在驗證功能真的生效？」

兩個結果沒有互相矛盾。

Command 確實成功執行。

Verification 也確實失敗。

只是團隊以前習慣把兩個 Success 當成同一種 Success。

Transport / Execution Success 和 Verification Success 不是同一層

很多 Automation Flow 都有一個很清楚的技術結果：

HTTP success
Command exit code = 0
Tool returned success

這些結果告訴你：

這次操作在 Transport 或 Execution 層沒有直接失敗。

但 Test Case 通常還有另一個問題：

原本期待的工作結果成立了嗎？

例如：

Command:
Enable feature

Transport result:
Success

Verification:
Feature state = disabled

如果只看 Command Result，Case 會被判成 Pass。

如果只看 Verification，又會讓人以為 Command 本身沒有執行。

所以 Package 的 Coding Rule 特別要求兩者分開記錄。

「成功」這個詞太容易被壓成一個欄位

Dashboard 最喜歡一個狀態：

PASS / FAIL

但在 Debug 現場，這通常不夠。

因為一個 Case 可能是：

Execution: PASS
Verification: FAIL

也可能是：

Execution: FAIL
Verification: NOT REACHED

這兩種 Fail 的下一步完全不同。

第一種表示動作有送出去，真正的 resulting behavior 沒有符合期待。

第二種則連執行層都沒走完。

如果把它們都壓成：

FAIL

AI 後面做 Log Analysis 時，也會失去最重要的 Failure Stage。

這裡驗的是功能，不是 API 回覆

建立或更新物件時，Readback 可以確認指定欄位是否真的落到預期 State。

Test Case 又多了一層外部條件。

就算 Command 本身正常完成，Assertion 仍然可以失敗。

所以 Completion Evidence 不能只來自 Tool 自己說：

我成功了。

還要看 Test 原本定義的 Verification Condition。

一個好的 Automation Result 應該分得出：

Action result
Verification result

前者回答動作有沒有完成。

後者回答原本要驗證的功能是否成立。

他們沒有把 Success 字樣拿掉

團隊最後沒有禁止 Tool 回 Success。

Command 成功就是成功。

只是 Report 改成兩欄：

Execution Result: PASS
Verification Result: FAIL

AI Summary 也不能把它縮成：

Operation failed.

而要保留：

Command completed, but the expected state was not verified.

這一句讓下一個人立刻知道該往哪一層查。

下一次，紅色沒有再引起爭論

幾天後另一個 Case 又出現：

Execution: PASS
Verification: FAIL

沒有人再問：

「明明 Success 為什麼還 Fail？」

工程師直接往 Verification 的 Expected / Actual 看。

Command Log 留在旁邊，證明執行層完成。

Test Case 仍然是紅的。

但那個紅色終於說得清楚：

不是 Command 沒成功。

是工作真正要驗證的結果，還沒有成功。