David Ko的學習之旅

Google, 相信大家都知道的軟體公司, 他的能力是有目共睹的. 可是你知道他們推廣測試自動化嗎?
 

因為極限編程 (eXtreme Programming) 和 DevOps 的出現, 測試自動化越來越受到大家的重視, 但是很多人雖然知道要做, 但是卻做不到. 常見的原因如下
 

很多組織有分成手動測試人員和自動化測試人員.
 

自動化測試要做到以下這樣是有點難度的
 

前一陣子在 Facebook 上的 Test Corner 和 Scrum Community in Taiwan po 文, 想知道大家的想法為何.
 

測試金字塔這個概念是由 Mike Cohn 所提出, 在敏捷測試圈很流行, 不過大家不太清楚他是什麼, 並且對它有很多誤解. 因此, 簡單整理了一下他的想法, 希望能對大家有幫助.
 

   
Gojko Adzic 是眾所皆知的名作者. 他所撰寫的 impact mapping, specification by example (有中譯本), Fifty Quick Ideas To Improve Your Tests, 和 Fifty Quick Ideas To Improve Your User Stories, 在市場上很受到歡迎. 這次他在 Agile Singapore 2016 介紹測試自動化的未來, 真的很值得一聽. 

在 agile tour Taipei 2014 中, 我們花了很大的篇幅, 安排了兩個 Coding Dojo, 讓大家瞭解如何來學習 TDD 的方法. 雖然 coding dojo 是個有效的方法, 但是並不是每個團隊能這麼幸運, 能夠來參加這樣的訓練.
 
   

在敏捷開發中, 我們都知道要將功能切割, 每次做些小功能, 然後持續交付價值給客戶. 
因此當你在開發每個小功能時, 你會不斷進行以下事情:
1. 從主幹 check out 程式碼到分支
2. 開發團隊在分支進行開發
3. 小功能開發完後, 將分支程式, merge 回主幹
4. 在主幹進行測試
可是通常這樣在第四步時, 就會遇到一堆錯誤. 這是因為小功能還沒確認是否正確, 就和整個系統和起來測試, 將導致問題多多. 如果有很多小功能要放進來時, 這種情況就會更惡化. 
因此有些團隊可能會這樣做:
1. 從主幹 check out 程式碼到分支
2. 開發團隊在分支進行開發
3. 開發完畢在分支進行測試
4. 在分支測試通過, 將分支程式, merge 回主幹
5. 在主幹再進行測試
這樣做之後, 可以讓小功能測試比較穩定後, 再放到主幹來. 可是遇到多個小功能同時開發時, 還是會遇到你進來的東西會跟別人不和, 導致整個系統無法運作.
所以下一步你會在這樣改進:
1. 從主幹 check out 程式碼到分支
2. 開發團隊在分支進行開發
3. 開發完畢在分支進行測試
4. 把主幹的程式 merge 到分支
5. 把 merge 完後的分支程式進行測試
6. 將 merge 完後的分支程式, 再 merge 回主幹
7. 在主幹再進行測試
因此你先確認小功能是否運作正常; 然後將主幹的程式合併到分支後, 再確認是否正確; 最後合併到主幹後, 在做一次確認是否都正常. 
看起來到目前為止, 應該考慮的很周到. 
可是... 有多少人這樣做呢? 似乎很少, 為什麼正確的事情, 大家都不做呢? 因為這樣反覆進行的測試工作, 如果你沒有自動化, 你就會沒有空, 或者討厭去做這樣的事情, 導致大家就很少去做. 
有些人說沒問題, 我們會把測試自動化搞好, 這是小事. 於是他們就開始處理測試自動化的問題, 接著你又會發現到:
要能自動產生 build, 否則每次手動要花多時間
測試環境要自動準備好, 沒有乾淨的環境, 測試結果可能會有影響
每個小功能整合到主幹後, 有可能之後出問題, 要重新回上個版本, 這個事情若是手動做, 也是件崩潰的事情 
……
所以再做下去, 你會發現整件事情沒有你想像的單純, 若是沒有落實 continuous integration 或是 continuous delivery, 你永遠沒有機會達到 agile 所說的, 每個 iteration 持續交付價值給客戶. 你所有的, 將會是至少落後一個 iteration 的交付. 因為在 agile 中, 每個 iteration 測試和開發要花的代價不同, 測試的代價是隨著 iteration 的進行, 逐漸高升.

上次在 InfoQ 中看到一篇文章討論測試自動化, 其中讓我印象最深刻的是有關測試工具.
在十年前, 測試工具大概由三家公司所佔據, 公司名稱已經不太清楚了, 目前大概只剩 QTP 活下來.  那時候第一名的市佔率, 大約是第二名的兩倍. 開源的測試工具那時候還不成氣候.
曾幾何時, 世界變了, 從 Google Trend 發現到, 當年市佔率約 30% 的 QTP, 衰敗到一整個不行, 開源的測試工具現在已經是席捲大地.
http://www.google.com.tw/trends/explore#q=qtp%2C%20%2Fm%2F025sf8g%2C%20Robot%20Framework&cmpt=q


為什麼會這樣呢? 我猜原因可能如下
1. 品質太差
其實寫這些工具的公司, 對於自己本身的開發品質也沒有好到哪裡, 因此所產出出來的產品也是 bug 連連, 每次都被我們恥笑, 是否有用自己的工具, 測試過自己的產品.
2. GUI 自動化其實是最沒用的
正如 Mike Cohn 所說的, 如果要做自動化的話, GUI 的自動化是最不建議的. 常常畫面有很多 object 它們無法辨識, 此外若是解析度一變, 或者測試機器 CPU 速度差很多, 這些錄出來 script 常常執行失敗. 時間一久, 你可能就不太會想投資他們.
3. 無法和開發流程搭配
工具通常會需要搭配開發流程, 可是這些工具廠商並沒有自己所謂的使用心法, 純粹只是畫面的錄製與播放. 像 Selenium 或是 JUnit 這些工具, 背後都有 ATDD 和 TDD 等理論支撐. 沒有劍法或是內功輔助, 神兵利器在手也是沒用.
4. 價格太貴
以前這種商業測試軟體, 價格大多是百萬起跳, 這不是大多數公司可以買得起的. 最慘的事, 是買完後還無法確定有用. 以前我們公司, 曾經把一堆公司叫過來來比賽, 只要能夠真的可以測試我們的產品, 我們就買的. 結果只有一家通過. 所以貴還不一定有用, 你還會想買嗎?
所以在 agile 出現後, 這個局面真的被顛覆了, 免錢品質又好的一堆, 所以正如安真說的: 我回不去了. 所以還不好好花時間研究這些免錢的工具 XDDD