在 agile tour Taipei 2014 中, 我們花了很大的篇幅, 安排了兩個 Coding Dojo, 讓大家瞭解如何來學習 TDD 的方法. 雖然 coding dojo 是個有效的方法, 但是並不是每個團隊能這麼幸運, 能夠來參加這樣的訓練.
此外, 除了個人技術的問題外, 還有很多非技術性的問題, 像是時程的壓力, 老闆的期待, 團隊成員的素質和自動化的策略等等, 你也必須要能夠解決, 單單只改進了個人技術能力, 還是沒有辦法讓整個團隊做出成績來的.
在我們的團隊中, 一開始他們並沒有自動化的經驗, 外加公司分工細緻, 開發人員不寫測試自動化, 測試人員不見得都有能力寫, 經理覺得開發人員不需要寫. 在這樣的有趣的環境下, 我們怎樣讓測試人員去做自動化呢? 以下是我們一些做法:
1. 找到有能力的成員
首先, 找到有能力的 team members 是必要的, 如果他沒有寫程式的能力, 我想可能任何人都很難推行測試自動化. 在台灣測試人員不容易找尋, 除了要能做手動測試外, 還要有能力做自動化測試, 這真的是超大難關.
很幸運地, 在花了 2 - 3 年時間, 讓大多數的團隊成員都具備這兩種能力, 或許無法每個面向都很強, 但是只要有工具人的能力, 就會讓團隊的調度容易很多.
2. 先求有
一開始目標是先設定為有測試自動化, 所以先試著要求對每個功能, 寫少數的測試個案, 或者是只針對重要的功能, 撰寫較多的自動化. 我們要的是開始做這件事情, 並不是要一開始就做到最好最棒, 因為你需要克服時程的問題, 你要讓工程師有時間學習. 更重要的事, 你必須在短時間內讓大家看到牛肉在哪裡. 這樣才能讓其他人願意追隨你.
3. 先打通技術難關
在寫自動化測試時, 你要先串通測試程式, 受測程式, 以及測試環境. 這個地方會是最困難的. 如果是開發人員直接來操刀, 難度會比較低. 但是如果是測試人員來寫, 時間就會拖比較久, 甚至會遭遇到一些技術性問題. 因此, 你可以請開發人員, 或者是程式能力較強的測試人員, 先把一些測試 scenario 寫出來. 之後其他測試人員就可以依樣畫葫蘆, 這樣就不會讓整個進度拖很久.
4. 要能天天執行
每天執行一次是最低要求, 最好是有 check-in 程式就需要執行, 要在最早時間點就確認是否會影響大家. 還有一種方式就是開發人員有一組 local 的 CI 環境, 在正式 check-in 到正式 CI 環境前, 就自己先確認是否有問題.
5. 要能立即修復
我會跟測試人員說, 一旦出錯後, 你需要在 5 - 30 分鐘內, 找出錯誤在哪裡. 並不是要威脅他們, 而是讓他們知道, 一旦測試沒通過, 會有很多人問說原因出哪裡, 並且因為天天執行, 你會被煩到不行, 為了你能從這個地獄解脫, 你必須從一開始就要好好精心設計, 讓你能在最短時間找出原因.
6. 加速執行時間
另外, 如果你要每次修改後就能執行, 那執行的時間就很重要, 因此你要想方設法, 讓你的測試在最短時間內完成. 否則上一個還沒結束, 下一個 check-in 又進來, 那測試要到何時才能結束, 修改的影響要何時才能知道.
最後要記住的, 測試自動化的重點在回歸測試, 也就是他重心並不是在找新的問題, 而是希望原有的測試個案能夠全數通過. 但千萬不要想說用這個東西去取代手動測試, 兩者各有所長, 沒有誰取代誰這回事.
那執行成果如何呢?
今年第一個專案, 一開始只有 12 個 cases, 中途來到 4X 多個, 等到 release 的時候大約有一百多個. 數字並沒有很漂亮. 但是, 但是大家覺得這個自動化很棒, 因為在 build 一被建立出來時, 就立刻告訴你是否問題, 很及時地讓你收到回饋.
接著, 執行第二個專案, 我就跟大家說, 你看之前那個專案自動化效果不錯吧, 有嚐到甜頭吧! 那我們就繼續吧, 所以大家沒有表示什麼異義, 就願意繼續嘗試下去. 可惜這個專案沒做多久, 就被老闆腰斬!!
然後在第三個專案, 我們又繼續推行自動化, 這次我們 case 已經到達 6XX 多個, 並且開始分種類來執行, 有分基本功能組, 詳細檢查組. 此外, 我們還把效能測試也加到每日的自動化執行, 所以你可很快知道, 這樣的修改是否對 performance 有影響.
明年會怎麼演進呢? 這可能要明年才寫得出來, 但是我們很高興團隊能有這樣的進展. 我們可以很驕傲地說, 開發人員做不到的, 我們來幫他們做到. 他們不能挑戰自己, 但是我們能 XDDD
全站熱搜
留言列表
