每次我在跟人家談論 agile, 我常說會不會 scrum 並不重要, 如果你能夠做到自動化測試, 那對團隊的品質就會有幫助, 可是很多人就會問說, CI tool 會不會要花很多時間, TDD 我不會寫, 也沒空用耶. 那我們要怎麼辦呢?
以下是我的一些經驗談, 希望能對大家有點幫助
1. 先可以動
要不要用 Jenkins, TeamCity 這些高檔 continuous integration 工具, 這個問題可以一開始先不用面對, 雖然工具很好用, 但是也是要花時間唸書的. 最快可能是用個 batch file 把大家組合起來, 然後放在 cron table 之類的機制, 讓它可以週期性執行起來就可以了. 這樣會花你很多時間嗎? 會需要很高深的技術嗎? 應該不用吧 XDD
agile 的精神就是一開始先做最小集合, 然後利用 iteration 逐步改進. 唯有立即看到結果, 你才能知道你問題出在哪裡, 你才能看到你的效果. 所以第一點就是先可以動.
2. 先做測試自動化
TDD 真的不簡單, 不止觀念上要改變, 連程式架構上都需要做些改變. 因此要大家能立馬開始用 TDD, 這真的有點難度. The art of unit testing 這本書的作者說, 從 unit testing 或是測試自動化開始, 會是一個比較好的選擇. 讓這個動作把程式品質顧好, 讓你有多點時間去學些好的設計 (而不是都花在解 bug 上面), 最後才來說要不要做 TDD.
3. 先有少量
剛開始時, 不要想說要有幾百個自動化的測試個案. 你只要每個功能寫個 2-3 個就可以了. 因為這是要讓大家養成習慣, 而不是要求大家在衝量. 畢竟一個新的東西, 老闆出一張嘴很容易, 但是學習需要時間, 改變需要心理建設, 這些都是需要時間的. 你要做的的是降低門檻, 提高接受度.
4. 先寫重要的
每個專案重要的定義不同, 但是先寫重要的, 讓這個投資是在最值得的地方, 這樣不管老闆或是員工, 都會覺得這不是件白工, 是個有意義的事情, 這樣要大家寫的阻力才會變小.
5. 先有樣本
有時候要測一個東西是有點難度的, 可能會比把那個受測功能寫出來還難. 這時候我會做的是請某位高手先寫 1-2 個案例. 之後再請別人接手. 這樣的好處是難關讓高手解決, 可以縮短時間, 讓他覺得有挑戰性. 然後讓技術沒那麼強, 或是不熟悉的人, 可以藉由這樣的來學習, 讓他們把依樣畫葫蘆, 把測試個案的數增加. 也不會讓高手覺得他都在做 routine 的工作.
6. 每天至少執行一次
需知道測試程式只要 1-2 沒有執行, 可能之後都不會執行通過的, 因為受測程式會不斷地修改, 如果測試程式沒有不斷執行, 去跟上受測程式的修改, 不一會就會沒用的. 為了讓你的測試自動化有效果, 每天至少執行一次.
不過, 最重要的, 還是你自己願意開始去嘗試, 想要跨出第一步. 否則不管大家分享哪些招數, 那都是別人成功的故事, 你永遠只有在台下聽的份 XDD
留言列表