上篇文章簡單扼要的說明了，如何透過驗收測試案例，來輔助驗證user story是否已經完成。

也強調了驗收測試案例的基本feature，該由哪些共同協同合作撰寫，以及這麼做的目的和好處。

接著這篇文章，則是要說明一下在軟體開發流程中，使用ATDD來進行的循環與過程。

上一篇文章：[Day 21]ATDD - Acceptance Testing
本系列文章專區
＠前言
TDD可以讓開發人員用小步伐的節奏慢慢累積可正常運作，且符合開發人員預期的程式碼。但ATDD關注的不一定是技術層面的事，而是在功能層面上確保「這個working software是否真的符合了使用者的需求」。

一開始透過user story抽象地定義使用者的需求，再依據如何定義user story已經完成，來break down成驗收測試案例。

有了驗受測試案例之後，我們才會開始著手建立一個可行走的骨架（Walking Skeleton），也就是先定義好使用者要什麼，才會明白系統或功能要怎麼撰寫。

定義好最後要怎麼通過驗收測試，才代表撰寫完成的系統或功能符合最終的需求。

＠ATDD的循環
先前有稍微提到TDD的循環，如下圖所示：

圖片來源：http://reddevnews.com/articles/2007/11/01/testdriven-development-tdd.aspx

ATDD以概念來說，循環可以先簡化成下圖的方式：

前提當然是user與PO, 測試人員先擬定好了user story（若在Scrum中，可能是PO依照sprint backlog來定義對應的user story），接著按照四個步驟的循環來進行：

1. 挑選一個user story
2. 撰寫驗收測試案例
3. 自動化測試
4. 撰寫實際功能內容

跟TDD很像，不是嗎？接下來我們針對這四個步驟來進行說明。

＠挑選一個user story
怎麼挑選一個合適的user story，這在實務上的眉角也很多，有興趣想深入了解的讀者，一樣請去讀Mike Cohn的User Stories Applied，筆者這邊只列出最簡單的原則：根據priority來選擇。

前面兩篇文章有提到，user story通常上面要記錄幾個東西：

1. user story內容
2. priority
3. 負責人
4. 驗收測試案例

註：user story通常由sprint backlog而來，sprint backlog由product backlog而來。

user story在設計時，通常也有許多原則要遵循，例如：INVEST model

INVEST指的是：

1. I – Independent（獨立）
2. N – Negotiable（可修改）
3. V – Valuable （對使用者有價值）
4. E – Estimable （可評估範圍）
5. S – Small （夠小）
6. T – Testable （可測試）

而滿足了這些原則，就會減少一些實務上挑選user story綁手綁腳的問題發生。（例如user story的相依性，影響到挑選的順序）

＠撰寫驗收測試案例
如同上一篇文章：[Day 21]ATDD - Acceptance Testing所提到的，用user story card記錄user story，可以在其背面記錄驗收測試案例，由PO(user), 測試人員與開發人員一同撰寫。

只專注在要測試的幾件事，也就是完成user story需要達成的幾件事。注重What，不注重How。建議可以透過一些工具輔助，以降低使用者或PO抗拒，並減少未來轉換成測試程式的成本，如文末的**＠ATDD工具段落**。

＠自動化測試
我們定義好需求之後，就是定義怎麼樣叫做完成需求。所以撰寫測試來驗證，功能是否符合預期。測試寫好之後，才來填肉，目標就是讓系統的程式碼通過測試。

簡單的說，除非測試案例寫錯，否則程式碼只要通過測試，就代表它是對的、是符合最終使用者的需求。這也是為什麼驗收測試案例需要各個角色的參與。

＠撰寫實際功能內容
為了要先滿足驗收測試案例，通常系統面的工作會先浮現出來，例如：

1. prototype:
   我們需要一個prototype，而且這個prototype可以讓使用者認同與驗收。它是一個working software，即使不完全，也可以表達出user story所需要的功能。

2. 環境：
   可能需要有測試機、測試DB、測試資料、測試file server、模擬的外部服務、介接的系統介面、使用的協定與資料格式。

這一些東西會被強迫在系統剛開始建置時，程式碼撰寫之前，一一浮上檯面。

這些東西在許多瀑布式或是一般專案中，可能都會等到程式碼開發完成才開始進行，但那時倘若出現一些差錯，都可能導致整個程式碼需要重新翻修。

透過ATDD，第一步就是先建立可行走的骨架，在撰寫任何程式碼之前，先確定環境建置，該透過模擬的元件或服務，系統的邊界，都會先被確定下來，以避免未來異動風險過高，或是不符合使用者需求的情況發生。

接著由user story整理出驗收測試案例，透過驗收測試案例產生整合測試案例，透過整合測試案例產生單元測試案例，一環扣著一環，top-down的往下設計下去，目標都是符合最終使用者的需求。填肉的過程則是有點bottom-up，但那無所謂，因為填肉的過程目標明確，每一塊肉，就是為了滿足某個測試案例而存在。

最終，原本的V-model就會演化成W-model，如下圖所示：

圖片來源：http://www.testingthefuture.net/2009/09/the-w-model/

＠User Story與ATDD
在Scrum的過程中，整個團隊在累積開發進度時，都是透過user story為單位來確認進度。把ATDD放在整個Scrum的sprint中，就如下圖所示：

圖片來源：http://www.methodsandtools.com/archive/archive.php?id=72p9

筆者一直在強調節奏，在Scrum的Sprint中，user story與ATDD的節奏就是：

1. 挑一個user story
2. 撰寫user story的驗收測試案例
3. 建立自動化測試程式
4. 完成user story
5. 挑下一個user story

＠ATDD與TDD的關係
了解了Scrum的流程後，而ATDD與TDD的關係，用下面這張圖來表示，再清楚不過了：

圖片來源：http://www.methodsandtools.com/archive/archive.php?id=72p9

1. 先撰寫user story
2. 為user story撰寫驗收測試案例
3. 撰寫驗收測試程式
4. 驗收測試結果失敗
5. 撰寫整合測試案例
6. 整合測試結果失敗
7. 撰寫單元測試案例
8. 單元測試結果失敗
9. 撰寫實際程式
10. 通過單元測試
11. 重構單元測試涵蓋的範圍
12. 重複step7~step11，直到整合測試通過
13. 重複step5~step12，直到驗收測試通過
14. 重複step3~step13，直到user story上的驗收測試案例全數通過
15. user story完成，挑下一個user story

＠Scrum流程的輔助
這樣可以在整個軟體開發的流程，讓整個團隊有著一定的節奏（這也是Scrum這個framework會定義一些固定的軟體開發流程的原因），這裡補上Scrum的流程圖：

圖片來源(by Ruddy Lee)：http://ruddyblog.wordpress.com/2011/04/03/scrum-%E8%AA%B2%E7%A8%8B%E5%9C%96%E7%A4%BA/

透過Scrum流程的輔助，來幫助每個角色在整個軟體開發流程中，各階段擁有一定的節奏。透過user story與ATDD的方式，讓開發人員與測試人員維持一定的節奏。透過ATDD與TDD與重構，讓開發人員在撰寫實際的功能程式碼時，也可以維持一定的節奏與品質。

有了節奏，有了測試的保護，就可以快速小步前進，持續回饋，持續演進，而且能夠更客觀的預估團隊的產出進度，且可以凝聚團隊向心力，建立信任基礎，這就是整套Scrum預期達到的效果。

＠小結
就開發團隊來說，開發流程就如下圖所示，一環扣著一環：

從user story開始，觸發ATDD，觸發TDD，觸發重構。

每一個環節，都是下一個環節的基礎。透過許多工具或開發方式，來降低每一個環節之間的轉換成本，讓每一個環節、每一個角色，最終目的都是產生一個最符合使用者需求的系統成品，這樣才是一個成功的軟體開發。

＠ATDD工具
這邊補充一下幾個常見的ATDD工具 (筆者比較喜歡表格式的呈現）：

1. Fit：官網
2. FitNeese (像Wiki的Fit)：官網
3. Selenium: 官網，也可以參考前面的修煉文：[Day 8]Integration Testing & Web UI Testing

這一系列會先以Selenium為主，當然還是可以輔以Fit或FitNeese來協助user或PO定義驗收測試案例。

如同前面修煉文內容所示，透過Selenium可以幫助開發人員建立後續的自動化測試程式。