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