完成對功能的了解之後,我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是,我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中,我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。
Acceptance Test Driven Development
驗收測試驅動開發(A-TDD)很容易跟 TDD(Test Driven Development,測試驅動開發)搞混,兩者是不一樣的概念。前者是關注的是溝通以及「用測試驗收更可靠」的概念,而後者則是一種開發上的技巧。
基於驗收測試開發的實踐,我們根據 PBI(Product Backlog Item)中細化(Detailing)後的關鍵案例(Key Examples)來撰寫驗收測試,這個資訊大多會包含:
- Given - 背景資訊,像是「這裡有一篇文章」
- When - 定義動作,像是「點選刪除按鈕」
- Then - 描述結果,像是「文章列表中找不到『文章 A』」
我們關注的是每一個功能(Feature)以及對應的情境(Scenario)發生的事情,這也是為什麼我們要進行衝刺計畫(Sprint Planning)來細化產品需求,將它轉換為實際的功能資訊。
因為使用「測試」我們很容易誤會要進行所有的檢查,然而 A-TDD 更加接近於「確認」這件事情上,因此我們每一個測試案例都是以「確認功能正常」為前提所撰寫。
Test Driven Development
因為我們基於 A-TDD 所撰寫了端對端(End to End)的測試案例,這也表示我們能夠用 TDD 的方式進行開發,採取「小步前進」的方式進行。
從使用者的角度來看,我們在初始的階段中只需要讓「文章列表找不到特定文章」的事情發生即可,因此我們很可能會直接在畫面中隱藏這篇文章,等待通過測試後,再繼續增加更細節的實作,直到我們完整的實現符合專案需求的功能。
透過這樣小步前進的方式,我們可以維持測試經常性的保持綠燈,也更容易在發生錯誤時倒退(Revert)回到上一個正常的階段繼續進行工作。