通常在接到需求單位所提出的需求後，開發工程師往往很急，就很早想要進入到程式開發的階段，希望能越早完成越好，然而往往事與願違，以我的經驗來說，我好不容易開發完成了，於是開始進入到測試階段(如下圖的開發流程)
但神奇的事情發生了，總是會有某種情況下，功能出現異常或是結果不對，這時候怎麼辦? 通常就是開始debug，找出問題的那段程式碼，偏偏這個階段就很吃你的人品了，有時很快就發現，有時找了老半天還是找不到，即使找到了，會發現要改很難改，程式幾乎要重寫甚至重構，因此我認為必須要改變開發的流程
改善後的流程增加了以下狀態:
1. 擬所有測試案例 : 這個階段要和需求單位討論會使用系統的USER，USER會有那些行為，他們會輸入什麼樣的資料，而且不同的角色、不同時間、不同資料，分別預期會得到什麼樣的結果
2. 規劃程式架構 : 如何設計方法或API階段，思考該方法會傳入什麼樣的參數，回傳什麼樣的資料，以及方法中的業務邏輯，可以參考先前的文章
3. 拆成模組 : 設計好一個模組或API後，若業務邏輯繁多(即程式碼篇幅很大)，就會開始切分成許多小單元，每個小單元我們稱之為模組
4. 撰寫模組 : 將3分析完後的模組，由程式碼實現
5. 跑所有測試案例 : 將1擬好的所有測試案例代入，驗證此模組的輸出是否符合測試案例，若符合即可開發下一個模組，
6. Debug(除錯) : 若有錯誤需進行程式Debug與修正，直到測試成功為止
由於在3階段已經拆成若干個模組，因此在4、5、6階段需要反覆不斷的疊代進行，直到整個系統開發完成且所有測試案例均成功為止
使用以上的流程有以下好處:
1. 程式較具有彈性 : 日後若有需求變更時，比較容易做調整與新增功能，不至於打掉重練
2. 及早發現及修正錯誤 : 因為在每個模組開發完就先進行測試，一旦有錯誤就能確定是當下正在開發的模組，且減少找錯誤發生的時間
透過我過去慘痛的經驗，我覺得寫測試案例非常重要，他就像登山時在步道上的標誌，提供明確的方向與指引，剛開始會覺得想測試案例很麻煩，但等到發現程式寫完後出錯，找問題才是惡夢的開始
