Testing in an agile environment

在敏捷式開發環境中進行測試

測試方法是敏捷式軟體開發中非常重要的一環, 除了讓軟體品質提昇之外, 還能讓開發需求在不停反覆的測試過程當中, 兩者差距越來越小, 良好的測試流程還能節省更多之後的維護成本. 在這邊介紹幾種大家最常討論的測試/開發流程:

Test-Driven Development 測試驅動開發 (TDD)

在正常的開發過程中, 我們先開發功能, 寫程式碼, 然後再測試它. TDD是一個反向過程, 先針對需求, 去分析要達成這個需求所要完成的各個小功能, 再將驗證各個小功能所要完成的測試寫成 Unit-Test, 再為了滿足這個測試, 來開發各個小功能. 再對開發完成的程式碼進行重構,

Behavior-driven development 行為驅動開發 (BDD)

行為驅動開發需要先將功能需求寫成明確的User Story, 藉由 Gherkin 這類用來描述 Feature 的語法, 來定義這個 User Story 需要完成的功能, 這邊要注意的是 User Story 要是真正的使用需求流程, 要避免是UI操作的流程或是程式的呼叫流程. 最後再根據定義, 去開發程式碼以及測試行為的UI-Test

實務經驗與困難

1.測試範圍:

在測試範圍如果寫的太過High-Level, 當Test Fail時, 並不能準確的知道該如何修正. 而當測試寫的太過於Low-Level時, 撰寫測試的時程需要非常長, 且容易有小功能的 Unit-Test 通過, 但結果並不如預期正確的情形發生.

2.測試成本:

在追求測試涵蓋率的同時, 除了撰寫測試的時間成本, 有時為了要測試所需要Mock或是繼承物件, 也要改動到原先設計的程式架構, 而產生更多隱性成本.

3.精準

User Story是否精準描述出真正的需求? 又或是 Test Case 是否有精準達到測試該 User Story 的目的, 這些精準在實務實作時都不一定是容易達到的.

心得

各種開發流程與測試方法, 不一定能完全適用在實際的開發流程上. 找出適合自己團隊的開發模式的這個流程, 本身也應該要像TDD與BDD一樣, 是個不斷調整與進步的循迴. 根據不同的需求, 開發環境, 以及參與人員, 再做不同的階段性調整.