在課堂上，我有一個幾乎每次都會問的問題。這個問題不複雜，但回答起來卻常常讓人遲疑。

「我會請學員回想自己最近一次專案，在內部測試階段，如果總共找到了100個 bug，他們直覺認為，其中有多少，是在照著測試案例一步一步執行的過程中被發現的。」

為了讓大家不要太快給出「政治正確」的答案，我會直接把選項寫在白板上：
100 到 80、
80 到 60、
60 到 40、
40 到 20、
以及 20 到 0。

然後我會請他們不要馬上舉手，而是先在心裡誠實地想一遍。

幾乎每一次，教室裡最後出現的分佈都很相似。大多數人會選在 60 到 40，或者再低一點的 40 到 20。選 80 以上的人不多，而選到接近 100 的，幾乎沒有。

這時候，我通常不會立刻解釋，而是接著問下一個問題：「那些不是從測試案例找到的 Bug，是怎麼被發現的？」

這一題，現場的氣氛往往會突然變得輕鬆，甚至有點尷尬。

• 有人說，是在測試過程中順手多點了幾下；
• 有人說，本來只是想確認一個看起來有點不合理的地方；
• 也有人很老實地承認，其實就是「亂玩」，結果系統就真的出問題了。

這些回答聽起來不像什麼高深的方法，甚至和我們在文件裡寫的「測試流程」有點距離。但如果你真的做過測試，你會知道，這些描述一點都不陌生。

很多關鍵的 bug，往往不是在你執行完第 37 條測試案例時出現的，而是在你心裡浮現一句話的那個瞬間：「如果這那邊按一下，會怎樣？」

這是因為測試本來就分成兩種行為。我們在測試過程中，做的事情並不只有一種。

有一部分時間，我們是在確認已知的規則是否正確執行；但也有一部分時間，我們是在探索那些原本沒被寫清楚、沒被想完整，甚至沒被任何人預期過的情境。

在測試領域裡，這兩種行為其實早就被清楚地區分開來。

前者，叫做checking；
後者，叫做exploring。

當你在做 checking，其實是在做什麼？當你照著需求文件撰寫測試案例，確認某個輸入是否得到預期輸出，或者在回歸測試中反覆驗證既有功能沒有被改壞，這些行為本質上都非常相似。你其實是在回答一個已經知道答案的問題：「系統有沒有照我們說好的方式運作？」

這類工作非常重要，也非常必要。它能幫助團隊快速發現明確的錯誤，避免已知問題反覆出現，也讓自動化測試有了存在的價值。

所以你熟悉的手動測試、單元測試、API 測試、CI 裡跑的那些自動化案例，本質上都在做同一件事：檢查我們已經知道、已經定義過的事情，有沒有被破壞。

然而，當你開始嘗試那些需求文件沒有寫清楚的狀況，當你刻意在流程中途跳走、回頭、重來，或者用一些「理論上不該出現」的資料去刺激系統時，你其實已經不在做 checking 了。你在做的，是探索。

探索的過程裡，你一開始並不知道正確答案是什麼，甚至不知道會不會真的找到問題。你靠的是觀察、推理、經驗，以及對風險的敏感度，一步一步往前試。

也正因為如此，很多高價值、但難以預期的 bug，才會在這個階段浮現。
它們通常不在 happy path，也很少被完整寫進測試案例裡。

為什麼只做 checking 的團隊，Bug 反而修不完？因為 checking 有一個無法避免的限制：你只能檢查你事先想到的事情。

現實中的需求，本來就不完整。使用者的行為會偏離預期，流程之間會互相影響，而風險往往藏在那些「沒人特別去寫」的地方。

如果你的測試活動只圍繞著測試案例，那麼你其實只是反覆確認一個「已知但不完整的世界」。真正未知、真正危險的部分，反而容易被忽略。

測試做得好的人，並不是測試案例寫最多的人。在我看過的團隊裡，真正成熟的測試工作，幾乎一定同時存在兩種節奏。

一種，是穩定而紮實的 checking，用來建立安全網，確保已知功能不會反覆出問題；

另一種，則是有意識地保留時間與空間，讓測試人員能夠探索、質疑、嘗試那些還沒有被定義清楚的地方。

他們不是不重視測試案例，而是不把測試案例當成測試的全部。因為他們很清楚，測試真正的價值，往往出現在你不知道答案的地方。

這樣的概念最早是在James Bach 與 Michael Bolton 在《Testing and Checking Refined》一文中所提出來。雖然是遠在2013年提出，可是在 GenAI 時代，卻變成是一條極其重要的觀念。

GenAI 天生就擅長 checking，但這正是風險的開始。生成式 AI 幾乎是為 checking 而生的。它可以快速產生測試案例、補齊驗收條件、撰寫大量斷言，甚至在極短時間內讓測試覆蓋率看起來大幅提升。從表面看來，這一切都像是品質成熟度的進步。

但問題在於，checking 從來就不是 testing。checking 只能驗證「某個命題是否成立」，卻無法回答「這個命題為什麼值得被驗證」。當 AI 依照模糊需求自動補齊規則時，它不是在幫你想清楚，而是在把未被質疑的假設快速合理化。

在 GenAI 時代，最危險的情境不是沒有測試，而是擁有大量建立在錯誤理解上的測試。AI 非常擅長產生「會通過的測試」，卻完全不在乎這些測試是否驗證了錯的事情。

這正呼應了James Bach 與 Michael Bolton的提醒：
品質不是事實判定，而是價值判斷。
而價值判斷，無法被完全機械化。

當團隊開始用「測試案例數量」、「自動化比例」、「覆蓋率曲線」來衡量安全感時，testing 其實正在悄悄消失，只留下 checking 的殼。

在 GenAI 時代，testing 變成一種「監督 AI 行為」的專業。testing 在今天的角色，已經不只是找 Bug。它更像是一種對 AI 行為的監督與質疑：

• AI 是不是替你補了沒人同意過的規則？
• 是不是在邊界、例外、狀態切換時放大了原本就模糊的需求？
• 是不是在「看起來合理」的地方，偷偷做了價值判斷？

這些問題，都不是 checking 能回答的。它們需要人類去觀察、比較、懷疑、反思，並且願意承擔「這樣設計是否真的合理」的判斷責任。

一個成熟的團隊，不是把 testing 全部交給 AI，而是非常清楚地知道：哪些事情可以自動化，哪些事情必須由人類來做最後判斷。

這正是《Testing and Checking Refined》在 GenAI 時代留下的最重要啟發：測試的專業，不是產出，而是判斷。