l

2017年4月10日 星期一

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

March 31 12:30~13:24

屏幕截图 2017-03-31 12.38.07

 

前情提要

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

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

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

***

瀑布式流程

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

屏幕截图 2017-03-31 13.10.17

 

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

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

***

測試後行的敏捷開發

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

屏幕截图 2017-03-31 12.54.04

 

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

***

測試先行的敏捷開發

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

屏幕截图 2017-03-31 13.03.32

***

結論

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

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

***

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

沒有留言:

張貼留言