第一章
(1) （是非題）「傳話遊戲」的問題在於：需求在轉述的過程中，每個人都可能加上自己腦內的細節，最後整合時才爆出版本分歧。
(True)
(2) （是非題）「用測試案例精神重塑需求」的關鍵，是把需求描述得像測試案例一樣具體：包含輸入資料、執行步驟、預期結果，降低模糊空間。
(True)
(3) （是非題）Gerald Weinberg 認為檢查需求最有效的方法之一，是使用「測試案例的精神」來描述需求。
(True)
(4) （是非題）生成式人工智慧（GenAI）能完全取代需求討論，因為它能自動補齊脈絡。
(False)
(5) （討論題）請解釋「測試＝需求，需求＝測試」的梅比斯環比喻。要做到這件事，PM/RD/QA 各自最重要的責任是什麼？
梅比斯環的意思：需求不是先寫完再交給測試；而是一開始就用可驗證的範例來討論需求，這些範例後來自然成為測試，測試也持續界定需求邊界，兩者是一體兩面、可流動。
三角色責任：
PM：說清楚價值與脈絡，協助把模糊想法變成可討論的驗收條件與重要情境，讓行為邊界清楚。
RD：用範例來設計與實作，指出技術上會影響行為的條件組合，確保可實作、可維護。
QA：看風險與邊界，檢視範例是否代表真實情境、是否漏掉錯誤/邊界，並協助建立可持續驗證的機制。
第二章
(1) （是非題）BDD、ATDD、SBE 雖然名稱不同，但核心精神一致，都是用具體範例讓需求更清楚、溝通更有效。
(True)
(2) （是非題）只要把 Gherkin 寫好、用 Cucumber 跑起來，就算完整落實 BDD。
(False)
(3) （是非題）BDD 的三階段中，「探索意圖（Discovery）」若沒有做好共同理解，後續的表述與自動化也很難有效。
(True)
(4) （是非題）實例化需求 (SBE) 主要由測試人員獨立完成，因為他們最擅長定義邊界條件與異常情境。(False)
(5) （討論題）用你自己的話說明：BDD、ATDD、SBE 各自最「在意」什麼？請各用一句話下定義
BDD 在意：
系統在不同情境下「應展現的行為」要用大家都看得懂的語言描述，並能連到自動化驗證。
例：用 Scenario 描述「8/28 訂 9/1 顯示折扣、8/29 顯示原價」並可用 Cucumber 跑。
ATDD 在意：
開發前先定義「完成的客觀標準」，驗收條件通過才算交付完成。
例：AC1/AC2/AC3 這三條作為交付標準，未通過就不算完成。
SBE 在意：
用具體例子把灰色地帶與假設攤開來，建立跨角色共識，最後把例子收斂成可驗證的規格/活文件。
例：用表格釐清「前五日（含）」到底包含 8/28 23:59 但不含 8/29 00:00。
(6) （討論題）請說明「行為驅動開發 (BDD)」的三階段結構（探索、表述、驗證）各自的重點為何？。
探索 (Discovery)： 釐清要做什麼及為什麼，透過對話找出模糊點與風險。
表述 (Formulation)： 將共識轉為結構化、可執行的情境文件（如 Gherkin）。
驗證 (Automation)： 將情境轉為自動化測試，指導開發並形成保護網。
第三章
(1) （是非題）範例（Example）的主要目的是作為測試工具，以確保測試覆蓋率達到 100%。
(False)
(2) （是非題）為了提高效率，團隊在需求探索初期就應該直接使用 Gherkin 語法撰寫範例。
(False)
(3) （是非題）一個完整的範例至少要包含三個部分：上下文（Context）、觸發的行動（Action）、預期結果（Expected Outcome）。
(True)
(4) （是非題）為了避免漏資料，一個範例應盡可能列出所有可能的欄位（例如身份證、信用卡、商品明細），這樣才可驗證。
(False)
(5) （討論題）範例要寫才算夠的原則，並說明範例與測試的關係。
原則是團隊覺得夠清楚即可，聚焦行為意圖與邏輯，而非所有情境；避免變測試模式，如輸入空字串/特殊符號屬測試而非需求探索。與測試關係：範例釐清需求，非測試覆蓋；若列太多易誤為負面測試，應問「夠清楚了嗎？」而非「所有測試了嗎？」。這樣讓範例幫助共識，而非堆疊案例。
第四章
(1) （是非題）Sprint Planning 是補寫需求與重新釐清範例的最佳場合，因為那時大家都在談要做什麼。
(False)
(2) （是非題）在 Sprint Review 中，團隊應該用既有範例逐一示範驗證成果，但不應在會議現場「直接修改範例」，變更應先記錄、下次 PBR 再處理。
(True)
(3) （是非題）LeSS中的多團隊PBR適合處理獨立需求，以提升效率。
(True)
(4) （討論題）瀑布三種情境（大批量／分批／不定期）裡，「範例討論的投資回收方式」有什麼不同？如果你是專案經理，你會怎麼選？
大批量循序：前期投入高、回收偏後段，主要是「避免後面整批返工」；風險集中在前期理解錯誤，一旦錯就難修。適合需求相對固定、規模大、後期改動代價極高的專案。
分批循序：每批回收一點價值、穩定累積改善；風險在「批次間不一致」與跨批次依賴沒管好。適合功能很多、但可分段交付、想降低一次性壓力的專案。
不定期需求：單次投入低、成效幾乎立即（減少日常摩擦），但高度依賴紀律與規格維護；風險是累積型（幾次沒記錄就崩）。適合營運中產品、需求零散插單的情境。
如何選：看你願意在哪個時間點承擔風險與壓力：要一次性「前期收斂」？還是「逐批校準」？或用「日常紀律」維持一致性。
(5) （討論題）在 LeSS 的 PBR 中，什麼時候應該用「多團隊 PBR」？什麼時候用「單團隊 PBR」？
用多團隊 PBR 的時機：需求跨團隊依賴高、邊界情境多、如果拆開討論會造成大量溝通成本或認知落差。
用單團隊 PBR 的時機：需求相對獨立、過去有類似經驗、跨隊耦合低。
第五章
(1) （是非題）大型全體工作坊最適合用於專案剛啟動時，讓所有人對業務有初步了解。
(True)
(2) （是非題）模糊投票（Ambiguity Polls）的主要目的是找出團隊成員對需求描述中潛藏的認知差異。
(True)
(3) （是非題）在專案啟動初期，對需求一無所知時，最適合採用「神勇三劍客（Three Amigos）」的組合來進行討論。
(False)
(4) （是非題）Example Mapping 討論中，如果出現大量的紅色卡片，代表該用戶故事已經非常成熟，可以立即進入開發階段。
(False)
(5) （討論題）為什麼 Example Mapping 會議通常建議設定 25 到 30 分鐘的時間盒（Timebox）？
認知效率：參考番茄工作法與認知負荷理論，25-30 分鐘是人類高強度專注討論的自然極限，超過此區間專注力會下降。
診斷工具：時間限制可作為需求成熟度的測試。若 30 分鐘內無法完成，通常暗示該故事太複雜（規則過多）或太模糊（問題過多），需要拆分或進一步釐清。
迭代節奏：符合 Scrum 團隊在精煉（Refinement）時間分配上的合理產出比例。
(6) （討論題）同一個需求從啟動到日常維運，你會如何「交錯使用」五種討論人選結構？請給一條你認為合理的節奏
啟動期：大型全體工作坊（1 次）
目標：讓所有利害關係人先共享同一張「業務地圖」，快速產出第一批範例與疑問清單。
需求釐清期：Three Amigos（每週 1–2 次，小而密）
目標：把模糊規則拆出可討論的範例，快速收斂邊界。
實作前：結對編寫 + 開發迭代前審查（每個迭代固定）
結對編寫：分析師/PM + 開發或測試，把範例變成「可驗證、可落地」的描述。
審查：資深開發針對「下個迭代」範圍做需求審查，提早打掉模糊點，避免返工。
日常：非正式交談常態化
目標：小問題即時釐清，但要有機制把共識回收（補到故事/範例/規則）。
第六章
(1) （是非題）在撰寫範例時，為了確保完整性，應該將 UI 操作細節（如點擊哪個按鈕、跳轉到哪個頁面）詳細記錄在驗收條件中。
(False)
(2) （是非題）在 GenAI 時代，使用結構化的格式（如 Gherkin）撰寫範例，其重要性在於能消除人類語言的模糊性，讓 AI 不需「猜測」規則邊界。
(True)
(3) （是非題）為了提高效率，一個 Gherkin 範例（Scenario）中可以包含多個 When 子句，同時驗證多個不相關的動作。
(False)
(4) （是非題）BRIEF原則中的「Intention revealing」強調範例應詳細描述操作細節與介面步驟。
(False)
(5) （討論題）你會如何用 BRIEF 原則，改寫以下「看起來專業但其實很差」的範例？
Scenario: 用戶id=1087成功下載文件
Given 使用者id=1087已經通過JWT驗證
When 點擊download_report按鈕
Then 伺服器回傳status code 200並輸出檔案
Scenario: Premium 會員可下載專屬報告
Given Sarah 是 Premium 會員
When 她嘗試下載「Premium 專屬報告」
Then 系統允許她下載檔案
And 系統顯示「下載開始」的提示訊息
(6) （討論題）為什麼「需求規格金字塔」建議範例應盡量往金字塔頂端（商業規則）靠近？
穩定性：底層的 UI 操作和技術細節變動頻繁；而頂層的商業規則（如折扣算法）相對穩定。
清楚度：商業規則是產品存在的理由，也是跨角色（業務、開發、測試）共享的語言。範例越靠近頂層，越能揭露核心邏輯，避免團隊陷入「怎麼操作」的泥沼，轉而專注於「為什麼要做」。
(7) （討論題）請說明「反例（Counter-example）」與「負向測試（Negative Test）」在需求討論階段的功用差異。
反例 (Counter-example)：主要用於需求探索階段。目的是發現需求描述的漏洞，將「隱性假設」轉化為「顯性規格」。例如：離島是否適用免運？它促使產品經理修正或補充業務規則。
負向測試 (Negative Test)：主要用於實作後的驗證階段。目的是確認系統面對錯誤輸入（如 SQL 注入、負數金額）時是否足夠強壯且不會崩潰。
第七章
(1) （是非題）等價類別分割法的核心目標是將輸入欄位區分為「合法」與「不合法」兩大類。
(False)
(2) （是非題）決策表測試法最適合處理單一欄位的輸入分類，而非多條件交互作用。
(False)
(3) （是非題）決策表測試法完成後，應把所有條件組合都轉成範例，才能確保需求完整。
(False)
(4) （是非題）並非每一個輸入欄位都需要建立等價類別，如果該欄位不影響系統行為，則不需要特別為其建立範例。 (True)
(5) （討論題）在釐清需求時，為什麼我們需要區分「角色」？請舉例說明角色差異對流程範例的影響。
角色是影響行為是否被允許的關鍵條件。同一個動作在不同角色下有完全不同的業務意義。
範例： 以「取消已付款訂單」為例，若角色是「管理者」，系統應允許操作並觸發退款流程；若角色是「一般使用者」，系統則應拒絕操作並提示聯繫客服。如果不區分角色，開發人員可能誤以為所有人權限相同，導致安全性風險或業務邏輯錯誤。
(6) （討論題）請比較「等價類別分割法」、「使用案例測試法」與「決策表測試法」三者在思考角度上的主要差異。
等價類別分割法： 從「資料」出發。關注哪些資料輸入會被視為同一類處理，將龐雜資料收斂為具代表性的類別。
使用案例測試法： 從「故事/流程」出發。關注使用者為了達成目標所進行的操作路徑（主流程、替代、例外），釐清動態的互動情境。
決策表測試法： 從「邏輯/規則」出發。關注多個條件組合下的決策結果，確保在複雜的 if-else 邏輯中沒有遺漏任何一種組合。
(7) （討論題）針對「車票變更」這類規則，你會如何用等價類別分割法，讓團隊不要陷入「列一堆欄位驗證」？請說明你的切分策略與範例選取原則。
第一步：列出影響行為的關鍵條件
根據規則，影響「變更」行為的變數不只是日期，還包含時間、次數與金額。我們列出以下欄位：
- 購票時間點：距離發車的時間。
- 已變更次數：該行程過去的變更紀錄。
- 新舊票價差異：變更後產生的金流變動。
- 變更項目：起訖站是否變動。
第二步：詢問行為分岔並劃分等價類
我們針對上述條件，尋找系統處理邏輯的「斷點」：
1. 購票時間類（行為：准許變更 vs. 拒絕變更）
- 類別 A1：發車 30 分鐘前（含） -> 准許進入變更流程。
- 類別 A2：發車前 30 分鐘內 -> 系統阻擋變更。
2. 變更次數類（行為：免手續費 vs. 須退票重購）
- 類別 B1：第一次變更 ->免手續費。
- 類別 B2：第二次（含）以上變更 -> 系統拒絕，要求退票（收 20 元）後重購。
3. 票價差額類（行為：退款 vs. 補款 vs. 無動作）
- 類別 C1：新票價 $<$ 原票價 -> 差額退回原帳戶。
- 類別 C2：新票價 $>$ 原票價 -> 原單刷退，重新付款。
- 類別 C3：新票價 $=$ 原票價 -> 僅更新行程紀錄。
第三步：挑選具代表性的範例
我們不需要窮舉所有組合，而是挑選出能代表「不同系統反應」的關鍵情境。
| 範例編號 | 購票時間 | 變更次數 | 票價變動 | 預期行為結果 (代表性意義) |
| 範例 1 | 發車前 1 小時 | 第一次 | 變便宜 | 成功變更 + 退差額 (最常見主流程) |
| 範例 2 | 發車前 1 小時 | 第一次 | 變貴 | 成功變更 + 觸發重新付款流程 |
| 範例 3 | 發車前 1 小時 | 第二次 | 任意 | 拒絕變更 + 提示需退票重購 (次數限制) |
| 範例 4 | 發車前 20 分鐘 | 第一次 | 任意 | 拒絕變更 + 顯示已過變更期限 (時間限制) |
| 範例 5 | 任意 | 第一次 | 變更起訖站 | 禁止操作 (規則強制限制) |
第四步：轉化為 Gherkin 驗收規格
為了讓團隊對齊理解，我們挑選其中最具行為代表性的範例 2 進行具體描述：
Scenario: 第一次變更行程且新票價較高，需引導重新付款
- Given 旅客持有一張已付款且未取票的車票（原價 500 元）
- And 該行程尚未有任何變更紀錄
- When 旅客於發車前 1 小時嘗試變更至票價較高的車次（新價 700 元）
- Then 系統應允許變更申請
- And 系統應提示旅客需重新支付新行程全額 700 元
- And 待支付成功後，原訂單 500 元應整筆刷退
第八章
(1) （是非題）使用 Few-Shot Prompting 的重點是給 GenAI 越多範例越好，才能讓它產出更完整。
(False)
(2) （是非題）決策表測試法的價值在於把多條件規則攤開，避免憑感覺補測試，並讓測試對應到可檢視的邏輯結構。
(True)
(3) （是非題）GenAI 在進行軟體測試時，容易寫出「形式正確但測不到重點」的內容，部分原因是因為它在訓練過程中學到的公開測試資料品質參差不齊。
(True)
(4) （是非題）在 Vibe Coding 模式下，開發者的角色會從系統的「實作者」轉變為「驗收者」與「規格制定者」。
(True)
(5) （討論題）從「Vibe Coding」的演進過程來看，為什麼最後需要引入「Agent Skills」？它解決了什麼問題？
在前幾個階段（TDD, SBE, 決策表），測試的成功往往依賴於開發者當下是否寫出了「精巧的提示語」或當下的「運氣」。
Agent Skills 將測試設計方法（如決策表分析）封裝成一個可重複呼叫的能力模組（包含目標、強制規則、執行順序）。
它解決了「一次性互動」的不確定性，讓測試能力不再依賴個人技巧，而是成為團隊中可複製、可長期維護的「工程資產」，確保 AI 的行為在不同情境下都是穩定且可預期的。
(6) （討論題）文中提到 LLM「形式正確但測不到重點」。請用你自己的話，解釋三個根本原因，並各舉一個可能帶來的實務後果。
原因一：訓練資料中的高品質測試稀缺（多為新手/過時/教學小例子）。
後果：產出漂亮的 Gherkin，但案例深度不足、風險薄弱，驗收時才發現漏掉關鍵例外。
原因二：看得到程式碼，看不到需求意圖（不知道為什麼這樣設計、哪些是商業風險）。
後果：測到「實作符合程式流程」但沒測到「行為是否符合業務目的」，最後變成做了很多無效驗證。
原因三：不懂風險權重，注意力平均分配（把小錯與大災難當同等重要）。
後果：把時間花在低風險情境（例如一般輸入錯誤），卻忽略高風險情境（例如金流衝突、權限轉移、並發造成的狀態污染）。
(7) （討論題）以 Vibe Coding 的「三角形判斷」演進為例，請比較：階段 2（TDD）與階段 3（SBE/Gherkin）各自解決了什麼問題、沒解決什麼問題？
階段 2（TDD）解決： 先用測試逼出可執行的驗收標準，提升實作穩定度、降低「憑感覺亂寫」；比起隨手 Vibe Check 更不容易一改就壞。
沒解決： 測試主要用程式碼語言呈現（Assert），非技術角色難參與，容易變成開發之間的默契；需求變動時也可能流於「為了讓測試過而改程式」，而不是回頭確認理解是否一致。
階段 3（SBE/Gherkin）解決： 用人人看得懂的行為範例當共同語言，讓業務/開發/測試討論「此情境該怎麼回應」；只要意圖不變，底層重構也較能維持範例穩定，降低長期維護成本。
沒解決： 需要建立新工作語言與節奏，前期討論與對齊成本上升；若條件組合複雜，仍可能需要決策表來補齊 GenAI 容易漏掉的角落。
發表迴響