ISTQB 在 2025 年 7 月推出「Testing with Generative AI」認證（CT-GenAI），2026 年 4 月更新到 v1.1。這是主流測試認證第一次正面回答：測試人員該怎麼用生成式 AI。
先說它的優點。這份大綱很誠實：
- 每個練習的最後一步都是「人工檢查」。
- 第 3 章特別設計了練習，讓學員親眼看 LLM 算錯。
- v1.1 把全文的「確保」幾乎都改成「提高機率」。連認證機構都不敢說 AI 能確保什麼了。
但它有一個根本的限制：它想像的畫面是「打開聊天視窗，寫好 prompt，貼上 user story，拿回測試案例」。這是 2024 年的樣子。現在用 AI 做測試的團隊，卡住的地方已經不在那裡。
下面是它沒教、但你一定會遇到的五件事。
一、它教你跟 chatbot 聊天，沒教你跟 agent 工作
大綱怎麼教
第 2 章佔了 365 分鐘，將近整個課程的一半。內容是：一個六要素的 prompt 格式（角色、脈絡、指令、輸入、限制、輸出格式），加三種技巧（prompt chaining、few-shot、meta prompting）。
Agent 只在 4.1.3 出現。v1.1 補了一段，承認現在的測試工具已經能讓 agent 半自主地跑完分析、設計、實作、執行、報告。但學習目標還是「看示範就好」。
問題在哪
一邊承認業界已經在用 agent，一邊花一半的時間教你怎麼跟聊天視窗對話。這個落差在 v1.1 反而更明顯。
現在的 agent 能讀你的程式碼、跑你的測試、看結果再修改。這種情況下，決定產出好壞的不是「這句 prompt 怎麼寫」，而是agent 拿到了什麼資料：它讀得到規格嗎？讀得到既有的測試嗎？知道這個專案的慣例嗎？
這件事叫 context engineering。簡單說：prompt engineering 是在教你「怎麼講話」，context engineering 是在問「這個新人上工前該讀哪些文件」。
該怎麼做
不要每次都想辦法寫一個好 prompt。把團隊的測試規則寫成 agent 每次都會讀的檔案（例如 CLAUDE.md 或 SKILL.md）。大綱裡的 meta prompting（讓 AI 幫你寫 prompt），在 agent 的世界裡大多已經被這種做法取代了。
二、它沒教你用測試技法管住 AI
大綱怎麼教
等價分割、邊界值分析，整份大綱只出現兩次：一次是說「AI 可以建議你用哪種技法」，一次是當評估指標的範例。決策表、use case、狀態轉換，完全沒提。v1.1 也沒補。
問題在哪
一份 ISTQB 的認證，教你怎麼讓 AI 產測試案例，卻不教你用 ISTQB 自己的 Foundation Level 技法去檢查 AI 的產出。
大綱的做法是：讓 AI 產案例，再讓 AI 產一張表，確認每條驗收條件都有案例對應。但這只能證明「每條都有寫到」，證明不了「沒有漏掉」。
舉個例子。驗收條件是「金額必須在 1 到 100000 之間」。AI 給你三個案例：50、0、100001。看起來有覆蓋。但邊界值分析會告訴你，至少要有 1、100000、0、100001 四個點。如果金額還有小數位數的規則，等價分割會再切出更多類別。
沒有技法當框架，你根本不知道 AI 漏了什麼。
該怎麼做
把技法變成 agent 的技能。例如決策表：先讓 AI 列出條件、動作、規則，你先檢查這張表；表對了，再讓它從每一條規則產案例。
這比「請幫我產完整的測試案例」可靠得多。而且人審查的是一張表，不是三十個案例。技法在 AI 時代的價值反而變高了——它從「幫人想案例的工具」變成「檢查 AI 案例的尺」。
三、它沒教你：AI 產得越快，瓶頸就往下游移
大綱怎麼教
大綱一直強調要人工驗證 AI 的產出。這是對的。
問題在哪
它沒有回答下一個問題：驗證的成本誰付？付得起嗎？
AI 把生成的速度提高了十倍，但團隊確認「這個東西是對的」的速度並沒有變快。結果是瓶頸從「寫得出來嗎」移到了「看得完嗎、敢不敢信」。這就是我一直在講的「驗證瓶頸」。
v1.1 在 4.1.3 說 agent 能「減少人工、縮短回饋週期」。減少的是生成端的人工。驗證端呢？大綱只有一句「對 agent 的結果實施自動化驗證」。這是標題，不是方法。
課堂上的練習規模小，「結果由人工檢查」行得通。真實專案裡，一個 agent 半天可以產出兩百個測試案例，「人工檢查」這四個字就是整個流程卡死的地方。
該怎麼做
不是更認真地 review，而是改變驗證的結構：
- 把驗證的單位變小：先驗表，再驗案例。
- 能自動的就自動：產出的測試先跑一遍，跑不過的直接退回。
- 依風險分配注意力：高風險的細看，低風險的抽查。
大綱 2.2.3 提了一句「依風險程度審查」，但沒展開。這句話其實是整個問題的入口。
四、它沒教你：AI 同時寫程式和測試時，誰說了算
大綱怎麼教
兩個版本都完全沒碰這個問題。
問題在哪
當 AI 從同一份 user story 同時寫出程式碼和測試碼，測試通過只證明一件事：AI 對自己的理解前後一致。它證明不了 AI 的理解是對的。如果 AI 把需求看錯了，它會寫出錯的程式和錯的測試，然後綠燈。
測試理論裡這叫 oracle problem：誰來定義「什麼是對的」？以前答案是「人」，透過規格和驗收條件。但當 AI 變成主要生產者，人寫的規格就從「參考文件」變成「唯一的真相來源」。它的品質決定了整條生產線的上限。
大綱有一個練習是「用 AI 從 user story 產生驗收條件」。我對這個方向有保留：驗收條件是人跟人達成共識的結果，價值在對話的過程，不在文字本身。讓 AI 代寫，等於跳過了讓它有價值的那一步。
該怎麼做
這就是為什麼 Specification by Example 在 AI 時代不是過時了，而是更重要。Three Amigos、Example Mapping、用具體範例把需求釘死——這些做法都是在 AI 動手之前，先讓人把「什麼叫做對」講清楚。
大綱說測試人員要轉型成「AI 輔助測試專家」。我會說得更具體：測試人員最不可取代的工作，是在 AI 開始生成之前，把正確的定義寫清楚。
五、它沒教你探索性測試和批判性思考
大綱怎麼教
大綱談的測試全都是一條路：user story 進，測試案例出。探索性測試只在 1.2.2 順帶提了一句，說 chatbot 適合拿來做探索性測試。
問題在哪
「user story 進、測試案例出」是 checking，不是 testing。
AI 很擅長 checking：已知的規則、已知的條件、已知的預期結果，它產得又快又多。但軟體最貴的 bug 通常不在已知的地方：規格沒寫到的互動、使用者不按牌理出牌的路徑、兩個功能疊在一起才出現的行為。
找這些東西靠的是探索性測試：帶著問題去用產品，從觀察中產生下一個問題。這需要的是人的批判性思考。AI 可以是工具，但不能是主體。大綱那句話其實說反了。
還有一層更基本的。大綱第 3 章教你辨識 AI 的幻覺和推理錯誤，方法是「交叉驗證、諮詢專家、一致性檢查」。這些方法都對，但前提是你得先懷疑。如果你對 AI 的產出預設信任，再多方法都用不上。
該怎麼做
批判性思考不是一項技巧，是整個工作的起手式。我在探索性測試系列裡把它講成「先懷疑，再共舞」：不是不用 AI，是先養成懷疑的習慣，再談怎麼跟它合作。
最後
v1.1 讓我確定了一件事：ISTQB 看得到 agent 正在改變測試，他們在 4.1.3 寫下來了。但認證更新的速度，追不上工具改變工作方式的速度。這不是 ISTQB 的錯，是所有標準化教材的宿命。
這份大綱標記出了主流認證認為「AI 時代的測試」是什麼。而真正的工作，多半在它的空白處。
發表迴響