驗收測試的核心觀念#

在所有 Clean Craftsmanship 的紀律中，驗收測試（Acceptance Testing）是程式設計師最無法獨力掌控的一項——它需要業務端的參與。然而，許多企業至今仍不願意適當地投入。

需求的真正本質#

全球許多組織透過 QA 部門執行大量手動測試來決定系統是否可以部署。當這些測試「通過」時，系統就會被部署。

這代表系統的真正需求就是那些測試——無論需求文件寫了什麼，只有測試才是真正重要的。如果 QA 執行測試後簽核通過，系統就會被部署。因此，那些測試才是需求。

驗收測試的紀律正是認清了這個事實，並建議所有需求都以測試的形式來規格化。

AAA 模式#

所有測試都遵循 Arrange/Act/Assert（AAA） 模式：

這三個元素可以用多種方式來規格化，但最易於理解的是簡單的表格格式。

上圖是 FitNesse 工具中的一個驗收測試範例，FitNesse 是一個 wiki，此測試檢查各種 markup 手勢是否被正確轉換為 HTML。其中 action 是 widget should render，input 是 wiki text，output 是 html text。

另一種常見格式是 Given-When-Then：

Given a page with the wiki text: !1 header
When that page is rendered.
Then the page will contain: <h1>header</h1>

這些形式無論是寫在驗收測試工具中還是簡單的試算表或文字編輯器中，都相對容易自動化。

紀律的實踐（The Discipline）#

角色分工#

在最嚴格的形式中：

• BA（業務分析師） 撰寫 Happy Path 場景的測試
• QA（品質保證） 撰寫探索系統各種失敗方式的測試
• 這些測試在功能開發的同時或略早之前撰寫
• 在 Agile 專案中，測試在 Sprint 的前幾天撰寫，所有測試應在 Sprint 結束前通過

測試即「完成」的定義#

• BA 和 QA 將測試提供給程式設計師，程式設計師負責自動化
• 測試的自動化語言必須是 BA 和 QA 能理解的語言——理想情況下，BA 和 QA 應該能直接用該語言撰寫測試
• 這些測試成為 Done 的定義：功能在所有驗收測試通過前不算完成；當所有測試通過時，功能就算完成

這對 BA 和 QA 是一項重大責任——他們撰寫的測試必須是功能的完整規格。驗收測試套件實際上就是整個系統的需求文件。

sequenceDiagram
    participant BA as BA(業務分析師)
    participant QA as QA(品質保證)
    participant Dev as 程式設計師
    participant Sys as 系統

    BA->>Dev: 撰寫 Happy Path 測試
    QA->>Dev: 撰寫失敗場景測試
    Dev->>Sys: 自動化測試
    Sys->>Sys: 執行測試
    Sys-->>Dev: 測試全部通過 = Done

從指導到獨立#

有些 BA 和 QA 團隊可能不習慣撰寫如此正式且詳細的文件。在這種情況下：

相關工具包括 FitNesse、JBehave、SpecFlow、Cucumber 等，但工具並非核心問題——軟體行為的規格化始終是指定輸入資料、執行動作、驗證預期輸出的簡單函式。

持續建置（The Continuous Build）#

一旦驗收測試通過，它就進入持續建置中執行的測試套件。

持續建置的運作#

• 每當程式設計師將程式碼簽入版本控制系統時（幾分鐘內），自動化程序就會觸發
• 該程序從原始碼建置系統，然後執行自動化的程式設計師單元測試和自動化驗收測試
• 執行結果會公開張貼，通常以 email 通知每位程式設計師和相關人員
• 持續建置的狀態是每個人都應持續關注的事

flowchart LR
    A["程式設計師簽入程式碼"] --> B["觸發自動化"]
    B --> C["建置系統"]
    C --> D["執行單元測試"]
    D --> E["執行驗收測試"]
    E --> F{"通過?"}
    F -->|"是"| G["公開綠燈通知"]
    F -->|"否"| H["公開紅燈警報"]
    H --> I["立即修復"]

持續建置的紀律#

持續執行所有測試可確保後續的系統變更不會破壞已完成的功能。如果先前通過的驗收測試在持續建置中失敗，團隊必須立即回應並修復，然後才進行其他變更。允許失敗在持續建置中累積是自殺行為。