LeSS in Action - 驗收測試驅動開發
完成對功能的了解之後，我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是，我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中，我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。
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）回到上一個正常的階段繼續進行工作。
分享至
成為作者繼續創作的動力吧！
2022 年四月，我參加了 LeSS in Action 的課程，在這個課程中我們要用一週的時間學習加入一間敏捷開發的公司並且實際產出程式碼，體感上就像是你工作了一年一樣，讓我們來看看這一週的時間發生了哪些事情吧？
