溝通的鴻溝：想像 vs. 執行#
開發過程中最常見的矛盾在於：客戶對功能的設想，往往無法承受電腦前真槍實刀的考驗。
人類語言是模糊的，但電腦程式須是精確的。
當業務方僅憑模糊的概念描述需求，而開發者試圖將其轉化為精確程式碼時，溝通的落差就此產生。
這引發了兩個核心問題：
1. 陷阱：過早精細化 (Premature Precision)#
| 概念 | 描述 | 核心矛盾 | 對策 |
|---|---|---|---|
| 不確定原則 | 業務方在專案尚未啟動時， 即要求精確預知最終結果 | 早期資訊極度匱乏與 需求的具體性衝突 | 承認早期資訊不足 |
| 預估焦慮 | 研發方尚未評估實作細節前， 就被迫做出精確承諾 | 技術複雜度未知與 時程死線的衝突 | 避免過早給出死板承諾 |
| 解決方法 | 學會 「推遲 (Deferral)」 與分階段精細化 | 隨著專案推進， 資訊完整後再細化 | 逐步精細化預估 |
2. 假性共識#
很多時候，研發和業務在交流細節時，雙方都「以為」達成了共識，直到交付時才發現南轅北轍。
- 解方：編寫自動化的驗收測試。這是避免誤解的唯一真理標準
什麼是驗收測試？#
驗收測試（Acceptance Testing）的定義很簡單：用來確定需求是否已經「完成 (Done)」的依據。
它是業務方與研發方之間的合約，必須具備以下特質：
| 特質 | 規範 | 細節與差異 | 預期價值 |
|---|---|---|---|
| 執行方式 | 盡量自動化 | 減少依賴手動，確保每次修改後 皆能快速、準確地驗證功能 | 提升回歸測試效率 |
| 對象視角 | 業務與測試導向 | 寫給業務方與測試人員， 而非僅供開發者理解 | 建立團隊共同語言 |
| 測試性質 | 非單元測試 | 黑箱測試，關注系統整體行為， 而非程式碼內部的運算邏輯 | 確保交付符合需求 |
Figure 7-1: Manual test plan
專業研發者的責任：
你有責任讓業務方、測試方都清楚明白「現在要做什麼」。
如果需求不明確，你就不能開始寫程式。
實作策略：面對 GUI 的挑戰#
編寫驗收測試時，圖形使用者介面（GUI）往往最棘手，因為它變動頻繁且難以自動化測試。
| 原則 | 策略 | 做法 | 預期效益 |
|---|---|---|---|
| 表象與本質分離 | GUI 僅是表象 | 體認到 GUI 只是底層抽象概念 的一種視覺呈現，並非邏輯核心 | 降低測試 對介面的依賴 |
| 針對穩定層測試 | 聚焦抽象元素 | 測試應針對背後相對穩定的業務邏輯 與資料結構進行驗證 | 提升測試腳本 的生命週期 |
| 繞過 UI 交互 | 直接呼叫 API | 透過 API 直接進行邏輯驗收， 而非糾結於按鈕位置、顏色或 CSS | 減少因 UI 改版 導致的損壞 |
驗收測試是需求的最終依據。沒有自動化的驗收測試，你就無法自信地說出「我做完了」。