l

2011年11月26日 星期六

用 Robot 寫自動化功能測試到底有沒有用 (2)

November 26 08:15~10:02

上次 Teddy 談到『用 Robot 寫自動化功能測試到底有沒有用』 這個問題,最近剛好把開發的系統做了一些『升級』,更是體會到『Robot...不能沒有你』。

***

各位吃『軟飯』的鄉民們應該會和 Teddy 一樣有相同的感慨,軟體開發久了,最後發現絕大部份的時間都花在『測試』上面。假設相同一隻程式(code)也許只要寫(改)個 10 次好了,光是測試可能就要 10 * N 次。這是什麼意思?假設你的程式要支援 8 個作業系統(Window XP,Windows 2003,Windows 2008,Windows 7,RHEL 6.x,SUSE 11.x,Ubuntu 11.x,CentOS 6.x),32-bit 和 64-bit ,以及 3 種瀏覽器(IE,Firefox,Chrome),Teddy 數學不好,請鄉民們自行算一下有幾種測試環境的組合。

你可能會說:『Developers 只要測試主要的開發平台(1-2 種平台),其他的找測試部門做平台相容性測試就好了啊』。『理想上』是如此,但是,如果你的 team 沒有配合的『測試人員或是測試部門』,那怎麼辦?你可以選擇『讓客戶幫你測 ...XD』,或是認命一點,自己測。

假設鄉民們和 Teddy 一樣都是『有理想,有 報復 抱負的 developer』,但是又不能因為這麼多的測試排列組合把自己給累死,那只能想想自動化測試的方法,讓『電腦』來代勞。寧可電腦累死,也總比你自己累死要來的好吧。


***

但是要讓電腦累死之前自己可能會先累死...XD...因為:
  • 要寫自動化(功能)測試案例。寫完一個 Robot test case 可能需要 4-6 小時的時間(包含寫這個 test case 和測試這個 test case 的時間)。
  • 要準備測試環境。光有自動化功能測試案例,沒有測試環境也是白搭啊。以剛剛 Teddy 提到的那 8 個作業系統的例子,至少就要準備 16 個作業系統(8 個作業系統各 32-bit 和 64-bit 一共 16 個)。

看到這邊鄉民們可能會大喊一聲...等一下....『我們可是窮苦人家的小孩耶,去那邊生 16 台電腦出來安裝這 16 個測試環境?』。關於這一點請參考『土炮跨平台自動化功能測試環境』裡面介紹的方法。什麼....你說:『用 VM 不就好了』...我還摻在一起做瀨尿牛丸勒....嗯嗯...這位『涉世未深』的鄉民,如果你的系統需要讀取硬體的資料,就不能用 VM 來當作測試環境啦。

如果鄉民們參考 Teddy 在『土炮跨平台自動化功能測試環境』裡面所建議採用『DRBL Server 管理測試 images』的方法,準備好這 16 個測試環境就沒事了嗎?當然不是,因為採用 DRBL Server 管理測試 images 的方式主要是用來在下班之後跑 nightly build,每次 restore 一個測試 image 可能需要 數分鐘 到 10 幾分鐘的時間,如果再加上執行 Robot test cases 的時間,一定無法滿足『Ten-Minute Build』的要求。如果要用這種方法在白天開發程式時拿來當作測試的環境,這種測試方法的 turnaround time 就稍嫌長了一點,developers 也不會想要去用(測試)。

那怎麼辦?兩種方法:

  • 多增加若干台『實體機器』以執行與硬體相關的測試:這些給 developers 在『白天』用來測試的『實體機器』,可以是原本完整測試環境的『子集合』。以前面提到 8 個作業系統的例子,最少可以只準備一台 Windows 64-bit 電腦與一台 Linux 64-bit 電腦就好了。Developers 在本機上寫好的程式可以丟到這些實體機器上面測試。
  • 增加一組或以上的 VM 以執行與硬體無關的測試:對於與硬體無關的功能,可以依據『公司口袋的深度 硬體測試資源的多寡』準備很多組 VM,例如準備上述 16 種完整的測試環境,或是完整測試環境的子集合。然後使用類似 Jenkins 這種『分散式持續整合系統』,當 developers 認為需要的時候,在 Jenkins 上面只要輕輕按下『建構按鈕』便可將所開發的軟體系統『同時丟到這些 VM 上面跑 Robot 測試案例』。那種感覺....很...過...癮...尤其是全部 test cases 都 pass 的時候....不過此種現象出現的機會大概跟 9 星連成一線一樣,百年難得一見....XD。

***


又扯了這麼多,你看的不累,Teddy 都寫到累了...XD。總結一下:

  • 要持續寫 Robot test cases:假設剛開始寫一個測試案例需要花 8 小時以上,熟了之後可能只需要 4 小時完成一個 Robot 測試案例。想到這個測試案例可以一直使用,這 4 小時的投資算是滿划算的。
  • 準備三種不同的測試環境:(1)用 DRBL Server 管理給 nightly build 用的眾多實體測試環境之 OS images;(2)準備若干台實體機器(通常是完整測試環境的子集合)給 developers 白天開發軟體與測試之用;(3)依據公司口袋深度準備若干(越多越好) VM,在白天上班時間由持續整合系統定期(例如每小時一次)或是由 developers 手動將自動化測試案例『同時』丟一組 VM 上執行。
  • 找專人持續關注測試案例執行後的結果。透過 UI 執行的自動化功能測試通常是很『脆弱』滴,很有可能因為『不明原因』執行失敗(有時成功,有時失敗)。因此,要指定倒楣鬼 專門技術人員...XD,持續關注測試案例執行結果。看看測試案例執行錯誤原因是因為程式錯誤,測試環境問題,還是測試案例撰寫問題,然後加以排除。
***

什麼,你問 Robot test cases 有沒有找到什麼問題?有啊,舉的例子,Teddy 曾經遇到過換了新版的 jQuery 之後原本 UI 上面的某個 check box 突然消失了 。這個問題就被『檢查所有網頁連結』的 Robot test case 給找出來了。那麼 Robot test cases 可以涵蓋到所有的軟體功能嗎?別傻了...當然...還沒有(需要時間和人力才能達到這樣的地步),所以,人工測試還是有需要滴。當人工測試找到新的 bug 時,要記得為此 bug 加上一個新的 Robot test case ,以確保日後如果相同的問題再次出現,可以被測試案例給逮住。這也算是符合 agile 精神... incremental growth... 持續做下去,就可以達到『顏回』不貳過的境界啦。

***

友藏內心獨白:禮拜六為什麼一大早就起床寫部落格...。

2011年11月19日 星期六

What Netscape learned from cross-platform software development (2)

November 19 21:14~22:29



第 1 集提到有兩種跨平台軟體開發方式:
  • 針對不同的平台從頭開發個別版本的軟體(基本上不同平台不共用程式碼)。
  • 軟體系統大部分的功能都採用 generic, cross-platform code 來開發(不同平台共用程式嗎碼),軟體中只有少部份與平台相依的程式碼。
Netscape 採用上述第二種方法來開發跨平台軟體,為此 Netscape 開發了一個稱之為 Netscape Portable Runtime (NSPR) 的元件作為跨平台開發的基礎,後來 Netscape 嘗試使用 Java 這個跨平台的語言來取代 NSPR 並用 Java 重新撰寫瀏覽器但是最後以失敗收場。


***


跨平台軟體開發除了程式語言的選擇以外,還有很多其他的成本。 根據 Netscape 工程師估算相較於單一平台的軟體開發,開發跨平台軟體需要至少額外 15%-20% 的人力與時間(design and coding 的時間)這還不包含整合與系統測試的時間(integration and system testing)


另外一個問題是『人力資源』的問題。例如,Netscape 的 server 部門只有一個 developer 熟悉 HP Unix,於是這個 developer 成為開發的瓶頸(可能有很多不同的團隊都需要用到這個 developer 的專長)。跨平台軟體開發團隊需要具備各種平台專家的人力資源,當此需求無法被滿足時就會影響到產品開發的時程。


另外一個更嚴重的問題是測試各種不同版本的軟體。根據某位 Netscape QA 經理的估計,與測試單一平台相比,測試 7 個左右不同版本的 Unix 軟體至少需要多 1 倍(double) 的時間。如果是測試 Windows NT 則需要更多的人力與時間。



***

論文最後一個要談的議題是軟體執行效率(performance)。Netscape 絕大部分的收入來自於販賣伺服器軟體(Web Server,LDAP Server, etc.),這些伺服器軟體執行速度要夠快才有賣點。根據 Netscape 工程師的估算,執行相同的功能,專為 Windows NT 所設計的軟體將會比跨平台的軟體至少要快 1 倍(at least twice as fast as cross-platform code)



綜合以上所說的種種問題,Netscape 改變了設計跨平台軟體的策略。在 Navigator 3.0 (1996 年 8 月釋出)與 SuiteSpot 3.5 (1998 年 2 月釋出) 這兩個軟體中,約有 20% 的程式碼是與平台相依的程式碼(platform-specific code)。到了 Communicator 5.0 時,裡面大概有 40% 的 platform-specific code這些 platform-specific code 絕大多數都是用來最佳化程式在 Windows 平台上的執行效率(應該是要跟微軟的軟體競爭)。


雖然 Netscape 原本的開發策略是『cross-everything』,但是後來 Netscape 的工程師把心力專注於最受歡迎的 Unix 平台:Sun 的 Solaris,而且不再所有的 Unix 平台上提供 Netscape 的產品。



***

最近這一段時間團隊也投資了很多時間在改善系統執行效率上面,因此讀完這篇 paper 讓 Teddy 感觸良多也感同身受。用講的太慢,乾脆用唱的...不是,是用條列式說明:
  • 在人力與資源不足的情況下,如果真的還是要開發跨平台的軟體,Teddy 也會選擇第二種方式(軟體系統大部分的功能都採用 generic, cross-platform code 來開發)。
  • Teddy 本身就是 Java -- write once, run anywhere -- 的受害者,也許 98% 的情況這句話都成立,但是剩下的 2% 就足以搞死你。
  • Performance 真的是開發完跨平台軟體之後最大的痛。聽到『你們做出來的軟體怎麼跑的這麼慢』的時候,真想靠...近...一點跟對方說....不然咬我啊...電腦該升級了...XD。
  • 『先研究可以動,再考慮最佳化』。跨平台軟體要先能夠做出來(能夠動),再看看那些部份對於 performance 影響最大(使用者最常使用或是最在意的功能),想辦法加以最佳化。
  • 需要撰寫 platform-specific code 的時候就放手去寫,想辦法從『設計面』來讓整個系統的設計保持一致,不要因為過多的  platform-specific code 導致系統無法維護或擴充 。
  • 最後一點,跨平台測試與整合真的很花時間。

***


寫到最後突然覺的中文不太好,快被 1 倍還是 2 倍煩死了...XD。



***


Java 內心獨白:Write once, run anywhere...公堂之上大膽假設一下,應該不犯法吧?!

2011年11月17日 星期四

為什麼不問問題?

November 17 20:40~21:40


2009 年 10 月下旬 Teddy 去參加了 Certified Scrum Master 兩天要價四萬新台幣的訓練課程。這麼貴的課,上課之前 Teddy 就想著要如何利用短短地兩天『多撈一點』,於是 Teddy 列了一個問題清單,大概有 10 來個問題,準備利用上課的機會來釐清這些問題。


到了上課那天,Bas (講師之一)準備了一個小板子,要上課的學員們如果有問題的話可以寫在紙上貼到後面(好像是一個人可以問三個問題...有點忘了)。此時 Teddy 就把準備好的問題列表拿出來,同桌的其他學員了嚇了一跳,想說怎麼有人那麼認真....^O^。


不過這不是重點,重點是,後來吃中飯的時候 Teddy 剛好坐在 Bas 旁邊,所以利用吃飯機會使出 Teddy 苦學多年的『菜英文』把準備好的問題跟 Bas 請教了一遍,算是頗有收穫。


***


上禮拜六 Teddy 擔任北科大 ezScrum 團隊所舉辦的 Scrum 分享活動的其中一場的講師(這個句子有點長...XD),Teddy 雞婆請主辦單位在活動前幾天詢問參加者如果有問題可以先將問題寄給主辦單位,這樣 Teddy 就可以針對參加者的問題先準備一下。


考考各位鄉民,報名的有 80 個人,請問主辦單位收到幾個問題?


有沒有 40 個?沒有。有沒有 10 個?沒有。有沒有 4 個?沒有。有沒有 0 個? !!!


雖然當天還是有不少人問了好幾個問題,但是問題五花八門有些問題『來的太突然』,Teddy 當下也不一定回答的很好。


***


會問問題真的是一門學問,Teddy 以前也是很不會問問題。記得念專科的時候,Teddy 要幫社團去借電腦教室(借一整個學期)。這間電腦教室是某位助教負責管理的,社團的前任社長(大 Teddy 一屆的學長)跟這位助教關係很好,所以之前已經成功借了一年。Teddy 要去借場地之前,前任社長與 Teddy 的對話...


前任社長:你要怎麼跟助教借電腦教室?


Teddy:就問助教說:『助教,這學期電腦教室可以繼續借我們使用嗎?一週兩個晚上。』。


前任社長:No, No, No。你要這樣說:『助教,這學期那兩天晚上電腦教室可以借我們?』。


Teddy:那有什麼不一樣?


前任社長:你的問法,是 Yes/No 的問句,助教腦中思考的回答是 Yes or No,萬一他說 No 這樣還要ㄠ回來就很麻煩。我教你的問法,是直接問他『那兩天可以借我們』... 雖然有點強迫中獎的感覺,但是我們都這樣問了,對方就比較不好意思回答『不借』。


Teddy:沒想到學長你『貌似忠良』,內心卻是如此狡猾...XD。嗯嗯...真是太厲害了,又學了一招。


***


上禮拜六 Scrum  活動中有鄉民問 Teddy:『一個團隊同時負責 5 個案子要怎麼 run Scrum?』。結果 Teddy 反問他:『如果你是國民隊的老闆,你會讓王建民早上跟洋基比賽,下午跟紅襪比賽,晚上再對上大都會隊嗎?小王年薪這麼高,不是應該一個人扛很多案子,好好利用他?』。思考完 Teddy 問的這個問題,原本鄉民所問的問題答案應該就很清楚了。什麼,還是不知道...來人啊,鞭數十,驅之別院...XD。


***

肯開口問問題就代表有在動腦筋(切記,開發軟體最難的一件事就是讓大家動腦),就算一開始問的都是一些很白目的問題,還是要勇敢的問出口,問到了,學到了,就是自己的。多問,多看,多學,就會進步。



***

友藏內心獨白:結尾好像太勵志了一點...XD。

2011年11月16日 星期三

What Netscape learned from cross-platform software development (1)

November 16 22:15~23:32


Teddy 在開發跨平台軟體這件事情應該不需要再多做解釋了,稍微瞄一下部落格內容就可以看到好幾篇和跨平台軟體開發相關的文章 。自從 Linux,iOS 與 cloud computing 愈來越流行之後,開發跨平台軟體的需求也變得越來越強。舉個例子,鄉民們應該都用過的 Dropbox,就有 Windows,Linux,Mac,iOS,Android 版的 client,是一個相當典型的跨平台軟體範例。


雖然開發跨平台軟體的需求越來愈強,但是 Teddy 覺的這方面的資料(論文,書籍,網路文章等)相對來講並不太多。之前 Teddy 寫過一篇『 無笑軟工:跨平台軟體開發的幾種技巧』,稍微整裡幾種開發與設計跨平台軟體的方法,今天稍微介紹一下前一陣子指導教授介紹 Teddy 看一篇論文:What Netscape learned from cross-platform software development, CACM, Volume 42 Issue 10, Oct. 1999(這個 pdf 檔是要錢的,但是用 google 找一下,可以找到一個 link 下載免費的 pdf 全文...不知道是誰放到網路上的...XD


2011 - 1999 =12,very good... 大家算術都很好,這是一篇 12 年前的論文,有點古老,可能比你的小孩年紀都還大,姑且以『考古』的心情來看一下這篇論文講些什麼。既然網路上可以下載到全文,Teddy 就以『大易輸入法』的精神直接講重點就好。


首先是背景介紹:

  • Netscape 在 1996 年瀏覽器佔有率高達 90%,但隨著微軟 IE 上市,1997 年尾 Netscape 市占率只剩不到 50%。
  • 和微軟相比,Netscape 最大的優勢是具備『跨平台設計與開發技術』。Netscape 的瀏覽器還有伺服器軟體(Web Server,LDAP Server, etc.)支援不同版本的 Windows 與 Unix, Mac。
  • 微軟的軟體雖然不能跨平台,但是微軟可以針對專屬平台對軟體加以最佳化。Netscape 軟體雖然可以跨平台,但是其執行效率相較於非跨平台的軟體是比較差的。
  • 為了維持競爭力,Netscape 必須要持續投資在跨平台軟體設計與開發技術上。
***

基本上有兩種跨平台軟體的開發方式:
  • 針對不同的平台從頭開發個別版本的軟體(基本上不同平台不共用程式碼)。
  • 軟體系統大部分的功能都採用 generic, cross-platform code 來開發(不同平台共用程式嗎碼),軟體中只有少部份與平台相依的程式碼。
Netscape 採用上述第二種方法來開發跨平台軟體。

***

接下來論文討論 Netscape 在跨平台軟體所遇到的挑戰:
  • 需要額外的時間與人力來設計抽象的,跨平台的程式碼。
  • 需要處理在系統中總是有一小部份的程式碼是無法跨平台的(總是會有若干與平台相依的程式碼)。
  • 跨平台測試與除錯(很花時間)。
結論就是,開發跨平台軟體需要更多的時間,而且系統的執行效率(performance)通常是會比較差(程式跑的比較慢)。這個問題基本上微軟在 1980 年代就遇到了,微軟在開發 Word for Windows 與 Word for Mac 時,採用一種與平台無關的 pseudo-code 格式,然後再將個 pseudo-code 編譯成 Windows 與 Mac 版。想當然耳,結果是大失敗。先不提程式執行速度的問題,有人會想在 Mac 上面看到類似 Windows 的程式介面嗎?這讓 Teddy 想到 Java 的 AWT....

後來當微軟開發 IE for Windows 與  IE for Mac 時,就採取之前提到的方法一:不共用程式碼,不同平台各自開發各自的版本。


***

Netscape 為了開發跨平台軟體,自己在公司內部開發了一個稱之為 Netscape Portable Runtime (NSPR) 的元件,讓上層的程式來使用。鄉民們可以把 NSPR 想像成一個作業系統抽象層,基本上提供了 file, print, socket I/O, threading...等等服務(對使用 NSPR 的上層 AP 而言 NSPR 是與平台獨立的抽象層,如果一定要打比方的話可想像成類似 JVM)。


***

NSPR 的確達到『節省開發人員時間(應該是說節省 coding 時間)』的目的,但是由於 NSPR 需要支援的平台實在是太多了,要開發與維護 NSPR 本身而言變得十分的困難。後來 1997 年早期 Java 語言出現,讓 Netscape 看到一絲希望。由於 Java 『天生』具備跨平台的能力,Netscape 假想如果能夠用 Java 來重寫所有的產品就可以避免掉之前所遇到的很多跨平台軟體開發的問題(真是太天真了...Teddy 知道鄉民們現在會這麼說...Teddy 約略在那個時期也上了 Java 『write once, run anywhere』的大當啊....大人,冤枉啊)。

由於 1997 年 Sun 的 JVM 還有很多限制,因此 Netscape 著手開發自己的 JVM,並準備用 Java/Javascript/HTML 重新開發一個 Java 版的 Navigator(Netscape 瀏覽器)。但是很快的,在1997 年晚期到 1998 年早期的時候, Netscape 的工程師就發現 Java, Javascript 還是太不成熟了,因此後來 Netscape 決定放棄這個 Java 版的 Navigator 的計畫。

簡單講,Java 雖然『天生是個跨平台的語言』,但是在當時由於缺少相關的工具(例如用來建立使用者介面的工具)以及『執行速度太慢(真的,當時 Java 給人的感覺就是....慢.......很多拍...啊...你說什麼...現在也是...XD)』,所以 Netscape 就放棄了在 client 端與 server 端使用 Java 的計畫。

***

差不多該睡了,今天先講到這裡,預知結果下回分曉。

***

友藏內心獨白:想到這句 Write once, run anywhere 到現在都還恨的牙癢癢的。

2011年11月15日 星期二

不會寫 unit tests

November 15 21:18~22:21


最近有一個朋友問 Teddy :『team members 不會寫 unit tests 要怎麼辦?』對於 Scrum (agile) teams 來講這算是很常見的問題。廣義的來說,不管是否採用 agile methods,只要想要實施單元測試的團隊,都可能會遭遇同樣的問題。


想當年(實在很不想寫這三個字 >_<)...Teddy 剛出社會的時候,根本沒聽過什麼叫做 unit testing,程式要怎麼測?就 programmer 自己測啊,用人工的方式來測試。一直到工作了幾年之後,那時候好像 JUnit 剛出來,Teddy 才開始學到 unit testing 的觀念。當時 Teddy 用的最多的語言是 VB(大概佔了 Teddy 所寫的程式 85% 以上),其次是 Java/JavaScript,再其次是微軟的 ASP。Teddy 第一個正式在工作上所寫的 unit test case 就是用 VB 寫的。當時還沒有免費的 VB unit testing framework 可以用,Teddy 依稀記得花了一點點錢在網路上買了一個商業版的 VB unit testing framework。當時 Teddy 的學歷是五專電子科畢業,從來沒修過任何軟體工程的課,更沒有修過軟體測試的課。不是要臭屁說 Teddy 有多厲害,而是要強調,寫 unit tests 這件事沒有那麼難。


幾天前跟指導教授提起這件事,指導教授說,在學校(敝校...XD)資工系大二的學生修程式設計的課就需要寫 unit tests。Teddy 當年在研究所修 OOP,OOAD 課程的時候也是有被要求要寫 unit tests。時代在進步,經此訓練相信新一代的 programmers 應該會具備寫 unit tests 的基本能力。


***


話說回來,對於已經在業界工作的鄉民們,如果有心想要寫 unit tests,該如何著手。先不談什麼 mock objects, stubs 這一類幫助做到 unit test Isolation的技巧,就單單講如何測試一個 class 的 methods 或是一個 C 程式的 function。


先講第一個方法:自修。不用急著去找書來看,網路上就有很棒的極短篇文章。這兩篇是 Teddy 覺的最經典的:


邊看邊用 JUnit 寫幾個範例,應該馬上就可以抓到單元測試的精神。如果嫌這樣還不夠,JUnit 網站還有一堆文章可以參考。


等 unit tests 寫多了,會發現怎麼自己寫的 unit tests 不是那麼 unit tests... 好像跟很多其他模組牽扯到,無法讓 unit test 跟『三輪車』一樣跑很快(難道是因為沒有老太太...XD),或是很容易因為相依的模組或是資料錯誤而導致 unit tests 執行錯誤。為了提昇 unit test Isolation,可以去找一些書來看。例如:
如果沒什麼時間(相信 99.99% 的鄉民都是屬於這一類的)那麼看第一本 JUnit in Action 就好了(鄉民內心獨白:七刀,知道我沒時間還叫我看書!),Teddy 當年也是看這一本長大的。想做 TDD 的可以參考一下第二本。至於第三本書則是非常的『凶險』,厚達 800 多頁,如果真的傻傻的想等看完再開始寫 unit tests,那......就有的等了。

以上都算是『unit testing 基本款』,如果有鄉民要問:『如何做 UI,Javascript,Web Services 等等的單元測試』,就請自行 google 一下,那有那麼好康什麼東西 Teddy 都幫你『傳便便』。



***


第二個方法是一個不花腦筋的方法:找人教。雖然說不花腦筋但是傷口袋啊...嗯嗯,傷口袋如果有學到真才實料也就算了,最怕的是『遇人不淑』,找到『說得一嘴好 unit testing』的人來教,結果教完之後還是不會。在這邊 Teddy 好心介紹 一批便宜的牛內 ...嗯嗯...一個管道,北科大 ezScrum 團隊除了有提供企業界導入 Scrum 以外,也有提供單元測試的教育訓練,經濟又實惠,有需要的鄉民們可與 ezScrum 團隊聯繫


***

啊...什麼,你說什麼,看完這一篇還是不會寫  unit tests...當然啊,Teddy 還沒資格來教鄉民們寫  unit tests,請自行覓食。


***

友藏內心獨白:有時候,花點小錢找人教反而是最省錢的方法

2011年11月13日 星期日

Scrum 分享活動答客問

November 13 16:28~17:47


趁著 Teddy 忘性還沒完全戰勝記性的時候,紀錄一下昨天 Scrum 分享活動參加的來賓們所問的問題。截至目前為止 Teddy 一共參加過三次 Scrum 經驗分享的活動,在進入正題之前,回顧一下這三次活動的差異。第一次是 ezScrum 正式發表的活動(免費),參加的人應該有將近 120 人左右,由於有王教授幫忙將活動資訊寄給校友,因此當天來的人有很多是畢業的校友們。在中場休息時間有不少校友是跑來跟『教授們』寒暄,所以印象中沒什麼人來與 Teddy 討論 Scrum 。


第二次是參加 MaoYang 所舉辦的活動,參加人數 35 人,報名費 350 元,活動現場有提供現磨咖啡。活動時間是週六下午 14:00-16:00,參加的人應該都是業界人士。中場休息時間有人來和 Teddy 討論問題,但是因為活動場地稍小,所以沒有辦法讓所有的人『圍毆 Teddy』,前前後後大概只有個位數的人來和 Teddy 扯了幾句。


這次活動報名的人數有 80 人(免費),實際到場的人應該沒那麼多。由於本次活動的休息時間有提供『咖啡,紅茶和小蛋糕等點心』,所以休息時間整個氣氛感覺比較好。而且場地也夠大,所以有形成若干個討論的小圈圈。另外一個原因可能是因為有一些人在公司內部已經有 run Scrum 的經驗了,所以討論的氣氛會比較熱烈一點。對了,對了,還有一個很重要的原因,就是因為這個中場休息時間『長達 30 分鐘』,也讓與會者有比較充裕的時間可以討論。印相中一般的活動休息時間好像都只有 15-20 分鐘左右,這『長達 30 分鐘』的休息時間效果還不錯(不想討論的人可以利用機會多吃一點..XD)


***


現在開始回想來賓的問題(Teddy 只依稀記得大概,所以可能會和當時的問題有點出入)...


Q1:我們有一個 team (約 6 人)同時需要負責 5 個案子,這樣要如何 run Scrum,例如如何開 sprint planning meeting?


A1:除非這 5 個案子都只是『維護專案』,否則建議『想辦法』讓一個 team 同時只專心負責一個開發專案。


後來根據提問者私底下表示,以他們目前的這種『1個 team 同時負責 5 個案子』的情況,有些案子搞了很久都還沒有結案。



Q2:Sprint planning meeting 時,有人一直出『無限大』的那張牌,表示『這個功能我沒做過,所以我不知道要出多少點(story point)』,請問該如何處理這種情況?


A2:王朝,馬漢,『狗頭鍘』伺候...嗯嗯....這種情況真的會發生,至於如何處理要看出牌那個人的
動機為何
。如果是有心想估算點數但是真的不知道要如何估,那麼如果是因為需求不清楚,就要請 PO 把功能講清楚,或是透過大家一來一往的互動,把『無法估算』的原因確切的找出來,不可能只用一句『沒
做過所以不知道要出多少點』帶過。如果是那種『存心找碴』的 team member,那麼為了會議可以順利進行下去,可以暫時忽略他,大家還是要保持『玩得很開心的氣氛』繼續估下去。事後 Scrum Master 要個別找此人溝通一下,如果真的『死性不改』那只能 (a) 想辦法把此人調到其他團隊; (b) 把此人歸類為 隱形人無效團隊成員』,不用特別去想此人能夠貢獻多少小時給團隊,把重點放在如何讓此人對於團隊的『殺傷力』減到最低。


就算是團隊中有剛報到且沒有業界工作經驗的新鮮人,Teddy 還沒遇過團隊成員經過討論後還 還敢 ...嗯嗯...一直出『無限大』這張牌的情況。


Q3:如果做 pair programming 時主管跑過來,看到『兩個人一起寫程式』會認為這是浪費人力,怎麼辦?


A3:如果主管會有這種想法那麼要先跟主管溝通一下 pair programming 的目的。從 Teddy 的角度來看,當團隊成員在做 pair programming 時,Teddy  心中都會暗暗比起『YA』的手勢,因為在大部分的情況下, pair programming 做出來的成品的品質 Teddy 會覺的比較放心一點。另外還有其他很多的好處,例如『互相監督...嗯嗯....應該是隨時在做 code review』,經驗交流等等。經常是 Teddy 要『跪求』團隊成員做 pair programming,而不是去擔心『為什麼需要兩個人一起寫程式』。

Q4:要如何在不告訴團隊成員我們要準備 run Scrum 的前提下來 run Scrum?

A4:(Teddy 內心獨白:這是什麼情況?!狸貓換太子現代版?) 嗯嗯...基本上這樣應該只能從 agile practices 開始。

Q5:Teddy 你有想要出書嗎?

A5:如果你可以先預購 1 萬本,我下個月就把稿子交給你...XD。



***


糟糕,大概只記得這些而已耶。另外要申明一點,以上回答完全是 Teddy 『跟著感覺走(憑當下的直覺)』的答案,不一定完全是 『Scrum 教科書』中所建議的方法,請小心服用。


補充一點,Teddy 當天問問題的時候有跟現場來賓們開了點玩笑,如果有人有『不蘇福』的感覺,Teddy 在此說聲抱歉,或是可以來信抱怨並換取 Scrum 普克牌一副...XD。


***


友藏內心獨白:記性這麼差,已經不是『初老症狀』,而是『衰老症狀』...XD。



2011年11月12日 星期六

Scrum 分享投影片

November 12 19:25~19:39


Scrum 分享活動結束。今天中午偷喝了一小杯咖啡,到現在胃都還脹脹,只好改天再來分享一下今天人客的問題。很高興本次的活動與參加的來賓們互動很好,認識了好幾位朋友(啊,Teddy 只拿到兩張名片...都不知道鄉民們的大名)。在『長達 30 分鐘的休息時間』中,有許多鄉民圍觀討論,讓 Teddy 非常意外...很高興 ^_^。也謝謝 ezScrum 團隊辛苦的準備。



Teddy 這一場的投影片可以在『這裡』下載。


***


友藏內心獨白:有鄉民看到 Teddy 居然斷定 Teddy 在帶 team 的時候一定很嚴肅... 難道留『平頭』的人看起來就比較像黑道....XD。

2011年11月6日 星期日

People over Process 番外篇

November 06 20:11~21:12


People over Process 寫了  (1),(2),(3) 還剩下一點點沒寫完,Teddy 又犯了虎頭蛇尾的老毛病丟著不管,反正也沒人發現...XD。這一陣子花了點時間在讀 The Design of Design 這本書,其中有一章提到了 design processes 和 great designs 之間的關係,最後作者(Frederick P. Brooks)的結論是:


Great designs do not come from great processes; they come from talented people doing hard work.


在台灣有許多公司用『製造生產』的觀念來看待『軟體開發』,認為只要有好的『開發流程(工廠作業流程)』,便可以產生『高品質的好軟體』。Brooks 告訴我們,很棒的設計是來自於有才能的人辛勤的工作成果,並非來自於偉大的流程。


路是人走出來的,軟體是人寫出來的。找一群普普的人,不管導入何種流程,要把軟體做好,有點緣木求魚的感覺。軟體開發的重點在於『個人的能力』,還有『團隊合作』。


市面上軟體工程相關的書籍以及網路資料那麼多,『阿斗仔』看的到,Teddy 看得到,鄉民們也都看得到。所以『獲得知識的困難度相對來講已經不是影響軟體開發的主要因素。先撇開國家文化與公司制度層面的問題,從『單兵(個人)』的角度來看,能否『傻的願意相信』這些方法是有用的,並且逐步加以落實才是困難之處。


Teddy 在『用 Robot 寫自動化功能測試到底有沒有用』提到,團隊前後花了超過一年的時間,才敢很大聲的以自身的經驗說出『用 Robot 寫自動化測試是有用滴』。這是因為團隊導入 Scrum 才可以獲得的成果嗎?並不是,因為使用 Robot 和採用何種開發流程並沒有直接的關係。還是因為 Teddy 很會寫 Robot ?也不是,因為 Teddy 根本沒有動手寫過任何一行 Robot test cases。這件事情能夠持續做下去,只有一個主要的原因:

  • 開發人員傻的願意相信,持續的投入,研究,分享,並解決許多技術上的問題。

雖然一開始是 Teddy 建議團隊採用(Teddy 是經由指導教授告知而得知 Robot 這個工具),並且一開始嘗試在每個 sprint  中安排寫 Robot test cases 的時間,但是如果開發人員在嘗試之後給 Teddy 負面的回饋,這個活動可能執行個短短幾個 sprints 就被終止了。在採用 Robot 的過程中,團隊也遇到了許多技術上的問題,也都自行想辦法克服,這才是這項活動得以持續下去的原因。


同樣一件事,找不同的人來做,極可能會得到不同的結果,這個道理,相信鄉民們都懂。有了好的人,加上好的開發環境與開發方法(流程),這樣的順序開發起軟體才可達到事半功倍之效果。


最後只剩一個問題:好的人哪裡找啊....
***


友藏內獨白:The Design of Design 天瓏書局有在打折,要買要快。





2011年11月5日 星期六

牛奶,奶球,傻傻分不清楚

November 05 20:04~20:35


前一陣子不是有一則新聞說很多市面上販售的『小米酒』,其實都不是用『小米』釀造的,而是用
『糯米』,因為
糯米的價錢比小米便宜很多。那為什麼不直接就叫做『糯米酒』就好了?鄉民們,托原住民的福,想必『小米酒』大家就算是沒喝過也都應該有聽過,名氣比較響亮。至於聽到糯米酒』只會讓人聯想起『麻糬』....


這種類似的案例還不勝枚舉,例如用『油魚』來冒充是『鱈魚』,或是用『智利鮑 (其實是一種螺肉)』來假裝是『鮑魚』。為了產品好賣,狸貓換太子有何不可。


今天 Teddy 也遇到類似的劇情。話說晚上 Teddy 到板橋車站地下街吃晚餐,用完餐之後想去吃個甜點,遠遠看到一家賣豆花的,菜單上面寫著:






Teddy 肚子還有點餓,想說來一碗『紫米牛奶豆花』好了,於是跟店員點了一碗。


店員:我們的豆花是黑豆花可以嗎?


Teddy:可以啊。


店員:<舀好豆花之後>.... 我們的『牛奶』是『奶球(就是泡咖啡的那種小小的奶精球)』可以嗎?


Teddy 內心獨白:頑皮,頑皮,推一推.....啊你真的是『空空免做乒』喔,怎麼會牛奶,奶球,傻傻分不清楚。


此時店員看到 Teddy 若有所思,於是說,那你也可以換成加兩樣料或是四樣料。


Teddy:那我加兩樣料好了,花生跟綠豆。


於是 Teddy 的『紫米牛奶豆花』,就變成『花生綠豆豆花』。


***

在店員幫 Teddy  加料(花生與綠豆)的時候,Teddy 對店員說,牛奶跟奶球應該是完全不一樣的東西吧,你們的目錄應該不能寫『紫米牛奶豆花店員連頭都沒抬起來看 Teddy 一眼,根本懶的回應,假裝沒聽到。


說得也是啦,看到紫米奶球豆花』會被吸引過去的有多少人呢?


***


友藏內心獨白:新北市的消保官電話幾號?





2011年11月4日 星期五

用 Robot 寫自動化功能測試到底有沒有用

November 04 21:43~20:50


使用免費且開放原始碼的 Robot Framework 來撰寫自動化功能測試也已經有超過一年的時間了,Teddy 曾在『土炮跨平台自動化功能測試環境』與『Automated acceptance tests』提過若干使用的經驗,今天想談一個問題:『用 Robot 寫自動化功能測試到底有沒有用』?

先定義一下何謂『有沒有用』,簡單的說,就是能不能在可接受的成本範圍之內,寫出測試案例並找到 bugs。如果可以,那就認為這個方法是有用的。要如何找?一言以蔽之『做  regression testing』,如何做?不花腦筋的方法:『每天晚上下班之後讓測試系統自動跑所有的 Robot test cases』,隔天早上再來看有那些 test cases 失敗,然後探討失敗的原因,看看是不是因為系統 bugs 導致的,如果是,就加以修正。


以上程序有做過自動化功能測試的鄉民們(無論是否使用 Robot 或是其他工具)應該都很熟悉,也沒什麼特別好說明的。Teddy 想討論的第一件事:『以 Robot 這種透過 UI 來做自動化功能畫測試的方法是否值得』?


有許多開發人員認為透過 UI 來做自動化功能測試是一種不穩定的測試方法,因為 UI 可能會經常改變,導致測試案例失敗,所以常常花了很多時間才發現『原來不是程式有 bugs,而是測試案例有  bugs (因為 UI 修改所導致)』。再加上,許多 UI 操作的 turnaround time(下達指令之後到該指令完成所花的時間)可能差異很大(尤其是在分散式系統中),這樣的功能要透過 UI 來測試系統就常常可能因為 timeout 導致測試案例失敗,但是實際上有可能只是某次的執行時間花的比較久一點(例如後端的資料庫正在忙碌,或是網路速度剛好很慢)。最後,自動化功能測試只能知道『該功能是否成功或失敗』,當功能失敗的時候,不容易直接看出原因,所以後續可能需要花比較久的時間來找出錯誤原因。還有一個開發人員可能不願意透過 UI 來做自動化功能測試的原因,那就是『這種測試案例不是很好寫』。


***

與『自動化單元測試(automated unit testing)』相比,自動化功能測試的確比較不好寫,因為後者要測的範圍比較大(透過 UI做 end-to-end testing)。在剛開始導入 Robot 的前 2-3 個月,Teddy 也一直在想同樣的問題:『讓團隊成員花時間寫 Robot 測試案例是否值得(到底有沒有找到 bugs 啊)』?因為剛開始的時候大家對 Robot 還不是很熟悉,所以寫一個 Robot test case 花的時間比較長,而且這些 Robot test cases 常常會因為『測試環境』的問題導致執行失敗。例如剛剛 Teddy 說過的 timeout 的問題(timeout 時間設太短),再加上測試環境的準備以及一些跨平台測試的因素,所以剛起步的時候幾乎看不出所寫的 Robot test cases 可以找出什麼 bugs,只能求這些 Robot test cases 可以穩定的執行。


為了讓撰寫以及維護 Robot test cases 可以持續正常,每個 sprint 團隊都有一個 technical story 是用來至少確保 Robot test cases 可以正常執行,如果還有時間則每個 sprint 還會持續增加幾個(個位數)新的 Robot test cases


看到這邊可能有鄉民會問,為什麼不把寫 Robot test cases 當作每一個 story 的驗收條件?這樣不是每個 story 完成之後就有現成的自動化功能測試了嗎?理想上這樣是很好,也許有人採用 Acceptance Test Driven Development (ATDD) 就是這樣做的,但是目前團隊並沒有採用 ATDD,每個 story 基本上會有單元測試以及手動的人工驗收測試,等 sprint demo 之後,確定沒有大的介面修改,才會在後續的 sprint 中找時間來『補寫』 Robot test cases。


***


導入 Robot 到現在也超過 1 年了,團隊成員寫 Robot test cases 越來越快,除了對工具本身熟悉度變高以外,還有 team member 熱心的寫了很多好用的 keywords (擴充 Robot)來加速撰寫測試案例的時間。Robot test cases 越來越穩定,當 test cases 執行失敗時找出原因的時間也越來越短,投資總算慢慢看到具體的回報(因為當 Robot test cases 失敗的時候,真的有找到系統的 bugs)。


有些 bugs 在單元測試的層次是不容易找出來的,因為問題可能出在 UI  端與後端元件的溝通上面。或是當整個系統整合起來時,想透過 UI 來測試效能的問題。又或是要確定最後打包的安裝程式是否能夠正常的安裝並執行,確認網頁上面每一個 link 按下去都是正常的。以上種種情況都還是需要做 end-to-end testing。


當看到 JUnit 上面都是『綠燈』的時候,程式設計師的心情會變得比較好一點。當看到 Robot test cases 都通過的時候,每個人的心情都會變好。每個 sprint 投資一點時間在自動化功能測試上絕對是頗值得的一件事。


***

友藏內獨白:『傻的願意相信』是很重要滴,團隊是在寫 Robot 之後,才學會 Robot 。