BDD（23）從規格、程式和測試思考BDD要解決什麼問題

March 31 12:30~13:24

 

前情提要

▲在〈三個圓圈（3）：規格、程式和測試〉文章中Teddy介紹了上面這張圖的意義，並在文末留下一個問題：

有沒有什麼方法可以讓區域1變得越大越好？指派專人撰寫詳盡的規格書有幫助嗎？Design by Contract有幫助嗎？組cross-functional team有幫助嗎？BDD/TDD有幫助嗎？這些都是值得思考的問題。

今天從這張圖來思考BDD如何協助團隊把區域1變大。

***

瀑布式流程

在談論BDD之前先看看傳統瀑布式（Waterfall）開發方法，如下圖所示，在瀑布式流程中一開始是撰寫需求文件，也就是定義規格。雖然在定義規格的同時也應該一併把驗證方式準備好，但實務上很少有團隊可以做到，能把規格書在期限內生出來就已經很偷笑了（第一個圈圈）。

 

有了規格書之後，當然要請客戶畫押，發誓不再修改規格。之後再依據這份規格開始寫程式（第二個圈圈）。雖著時間演進程式越寫越多，但此時不知為何規格也跟著改變與膨脹（第三個圈圈）。好不容易等程式寫得差不多了，雖然沒有涵蓋全部的規格，但截止時間快到了，只好硬著頭皮先丟給QA部門測試（第四個圈圈），並且利用測試時間再繼續偷偷開發未完成的功能（第五~六個圈圈）。

以上所說都還算是負責任的情況，有時候趕著上市連最後的測試時間都沒有，直接丟給客戶請客戶幫忙測。在這種情況下，規格、程式和測試三者重疊的區域要大到哪裡去說真的不太容易。

***

測試後行的敏捷開發

敏捷開發團隊不須把所有規格都定義好之後才可以開工，以Scrum為例子product backlog有足夠接下來1~2 sprints的user story就可以了（第一個圈不需要很大）。下圖中的黑色圈表示規格，紅色圈表示程式，綠色圈表示測試。對於沒有導入BDD/TDD的敏捷開發團隊，開發順序先寫production code再寫test code，所以先有紅色圈再有綠色圈。基本上程式的範圍由user story的驗收條件所規範，而測試案例也可以參考這個驗收條件來撰寫。加上user story的粒度相較於傳統規格書的一個功能要小很多，因此比較容易讓規格、程式、測試三者重疊。

 

但是，有不少敏捷團隊雖然有事後「補寫」測試案例，但也常常因為sprint時間的限制只把程式寫完而來不及讓綠色圈與紅色圈重疊（測試不完整）。長期累積下來規格、程式、測試三者重疊的區域就大幅減低。

***

測試先行的敏捷開發

測試先行的作法利用測試案例來劃定規格的範圍，接著再撰寫程式。只要程式通過測試案例，既代表滿足規格所需。這樣的順序「理論上」可以大大地增加規格、程式、測試重疊的範圍。這裡有一個很重要的前提，使用測試案例所規範的需求要具備代表性，也就是《Specification By Example》書中所說的「關鍵範例（key example）」，否則一開始測試和規格重疊的部分就很小的話，後續依據測試所寫出來的程式也不可能涵蓋原本的規格。

***

結論

許多軟體開發方法都嘗試著增加規格、程式、與測試的重疊範圍。BDD透過兩個關鍵的做法來達到這個目的：

• 透過協作來探索規格的範例。
• 透過測試案例作為規格的代表，自動驗證規格與程式是否一致。

***

友藏內心獨白：BDD從流程上避免三者發散。