主要流程走得通，還有哪些地方我沒驗到？

前兩篇寫到，我現在會先用測試和 AI review，確認已經定義的行為有沒有成立，以及實作方式有沒有偏離原本的設計和系統分工。

但這些都通過之後，我還是會自己把 UI 打開，從使用者真正會進入的地方開始走一次主要流程。

我自己操作時，主要是在確認：

這個功能放回真正的工作情境裡，使用者是不是能合理地把事情完成。

有時候規格要求的功能都有做出來，測試也通過，review 也沒有重大問題，但我自己一操作，還是會覺得畫面太複雜、資訊太多，或者操作方式不符合這段工作的節奏。

這些問題，只有真的把功能當成使用者來操作，我才比較容易看出來。

但我也知道：

自己這樣走一次，主要驗到的就是 Happy Path。

主要流程走得通，只代表一部分成立

Happy Path 就是最正常的情況。

資料完整。

條件都成立。

使用者按照預期順序操作。

整件工作可以一路完成。

這條路當然很重要。

如果連主要流程都走不通，功能根本不能使用。

但真正的工作現場不會永遠只有這一種情況。

只要改一個條件，可能就會出現另一種結果。

換一個角色。

資料少一欄。

中途失敗。

操作到一半取消。

重新進來。

同一件事情換一個順序做。

甚至系統裡原本就有一個不正常的資料狀態。

這些情況我知道存在。

真正困難的是：

我不知道哪些一定要驗。

知道有例外，不代表知道怎麼驗完整

這也是我目前很明顯的能力邊界。

我不是直到現在才發現 Happy Path 不等於完整 QA。

這件事我本來就知道。

真正還不會的是：

要怎麼把 Happy Path 之外的情況有系統地整理出來？

哪些風險最高？

哪些角色一定要分開驗？

哪些資料狀態最值得測？

什麼算邊界條件？

哪些情況只需要自動化測試，哪些一定要真的操作一次？

又要做到什麼程度，才可以合理地說：

這次驗證已經足夠？

目前這些問題，還超過我的能力範圍。

專案裡有很多驗證，不等於我已經會做 QA

現在這個專案當然不只有我自己人工走主要流程。

有自動化測試。

有 AI review。

有既有規格。

也有不同環境與部署上的檢查。

所以實際上，很多我自己沒有手動走到的地方，專案裡仍然可能已經有其他方式在驗。

但這和「我自己已經會判斷完整 QA 應該包含什麼」是兩件不同的事。

即使專案裡有很多測試，我還是要先知道：

哪些重要情境本來就應該被測到？

如果這一題沒有形成自己的判斷，就很難只因為：

測試很多。
CI 全綠。
review 已經收斂。

就直接得出：

重要風險都已經被覆蓋。

真正的缺口，是不知道自己漏了什麼

這和前面幾篇的問題不太一樣。

Day 25 裡，測試是在約束已經被寫下來的期待。

Day 26 裡，review 是重新檢查實作有沒有偏離設計和既有系統。

而我自己操作 UI，則是在確認主要工作路徑能不能真的合理完成。

這三層我現在都知道大概在做什麼。

剩下比較陌生的是：

那些還沒被寫進期待、還沒被 review 點出來、也不在我主要操作路徑上的情況。

它們到底有哪些？

哪些最重要？

怎麼有系統地找到？

這才是我現在真正還不會的部分。

這是一個我知道存在，但還沒有能力回答的問題

前面一路寫到這裡，我對「AI 做完之後怎麼建立信任」已經比以前清楚很多。

我知道不能只看功能有沒有動。

也知道不能只靠一種驗證方式。

不同層次會看到不同問題。

但到了 QA 這一層，我目前還不能很有把握地說：

我知道自己到底還漏了哪些情況。

所以這篇最後沒有一個完整答案。

我能確定的只有：

主要流程走得通，只代表我驗到了一部分。

而我接下來需要學的，是：

怎麼知道那些沒有走到的地方，哪些也不能漏掉。