VIVOTEK Digest

經濟部統計處: 飲料店營業額在台灣逐年攀升

第一個常見現象：開週會
Why are meetings so ineffective?

Great movies tell stories that have deep emotional resonance

第二個常見現象：同事間的工作互換困難
Why is collective work difficult?

Machine learning or human learning?

第三個常見現象: 加班

Why work overtime?

不同角度的生命科學系

又下班了?! 我還想工作

Schrödinger’s Cat 薛丁格的貓

敏捷開發
Why OverCooked can teach you agile?

一款具備敏捷精神的遊戲

Get back in sync

Realtime review

The programmer as navigator

How to avoid boring meetings?

How to develop a cohesive team?

合作或協作（英語：Collaboration）

是指一種由兩個或兩個以上的個人或團體作為一個共同的目標而交集或在一起共同工作，舉例說明：

一個知識分子可以透過合作的關係而去分享知識，再而經過學習和共識達到創作的目標

一個人走得快

一群人走得遠

 Why collective intelligence matters?

Pacific Rim: Uprising (2018)

True collaboration yields better results

Iteration based method

Jeff Patton did an Iterative Mona Lisa.

敏捷帶來的影響
How does agile affect my work and daily life?

從同事電腦辦公桌

變家人散步吹吹風

關門 SOP

前是把家當旅館

現在是家事盡量管

一直都是使用 Robot Framework 來進行自動化的 UAT，但因為完整的 UAT 還包括了手動測試的部份，因此在 UAT 中 Test Case 的管理上就比較麻煩一點，可能完整的 test case 是存在 excel 裡頭，再由開發人員手動填入 Robot Framework 的測試結果。
這樣真的太低級了，這不但浪費時間、易出錯，而且很難管理啊，所以必需有一個更好的管理方式。
為了解決這個問題，我們導入了 TestRail。TestRail 是一套相當好用的 Test Case / Test Plan 管理系統，而且 API 相當完整，因此拿來跟 Robot Framework 整合真是再適合不過了。使用的流程為：

• 在 TestRail 中建立Test Case
• 如果該 Test Case 有對應的 Robot Framework 自動化測試 test case，記得在 test case 中的 Tags 欄位加上 CID:n，這個 n 便是在 TestRail 中的 CID(Case ID)
• 當產品要進行完整測試時，便建立一個 Test Run，然後由 CI Server 呼叫 Robot Framework 開始進行自動化測試，接著再自動把測試結果更新到 TestRail 中對應的 Test Run Result 中(passed/failed)。接著團隊便可以知道還有那些 Test Case 未經測試(untested)，只要針對這些 test case 去補足手動測試即可。

其中比較麻煩的便是 Robot Framework 的結果要如何傳入 TestRail，因此我們做了一個小工具來進行分析 Robot Framework 執行結果，並搭配 TestRail API 來進行更新，完整的程式碼已放在 github 上:https://github.com/diro/robot-testrail

1. 那誰要去驗證你寫出來的驗證程式正不正確.
2. 就是我說的這個測試只能針對UI, 而不能是對整個solution做測試, 因為沒有測到client拿到sever資料以及組完model時的正確性.
3. 想看看最前線寫test case的人員是DQA(或是PO跟user討論), 我想他們百分之百不會想到要用程式去產生一份驗證資料出來. 對DQA而言, 他們一定會先定義好測試條件跟環境, 然後針對各種條件就先把驗證資料蒐集好了, 這樣測試時才可以拿來跟solution得到的結果比對.

1. 測試環境跟測試參數
2. 測試步驟
3. 驗證的資料

Unit test (單元測試) 在我剛開始加入團隊的時候，有寫過一陣子。那時候使用的是內部人員自己開發的 framework。當時寫 unit test 的方法可以說相當原始，我們沒有特別去研究 unit test 可以怎麼作，stub 或 mock 更是沒有研究過的議題。大家就只是很努力地在每個模組完成後，補完大部分可能的 test cases。但是久而久之，隨著專案越來越大，架構越來越複雜後，寫 unit test 變成一個令人沮喪的活動，至少當時對我而言是這樣。原因是甚麼？

多年後，我在團隊中又剛好擔任到導入 unit test 的第一線角色。現在因為開發經驗比較豐富，對於測試應該怎麼寫，或是寫 unit test 的人應該專注於哪一部分有了一點點的感覺。在我還是個懵懵懂懂的 RD 時，覺得每次寫一個新模組的 unit test，前置大概要花好幾個小時，在寫一些該模組與其他元件「假」互動的部分，例如與資料庫溝通的模組，透過網路傳送訊息的類別，跟串流伺服器傳輸影音的函式庫。因此，寫久了會問自己，到底是在寫單元測試還是在寫假類別的程式。

[圖片來源: www.wowwiki.com]

在這一次的 unit test 導入計畫中，我們選用了 Google C++ Testing Framework，這部分其實跟之前試用過的 boost 中的 unit test framework 大同小異。同時我們也使用了 Google C++ Mocking Framework，我花了一天的時間閱讀了相關基礎文件後，頓時有種為什麼以前要花時間寫那些「假」互動。原來以前花很多時間在做的事情，使用 framework 只要幾分鐘的時間就完成了，也因此寫 unit test 的人可以真正的思考測試的流程或是設計測試的不同案例。我為了讓實際開發者能專注於如何寫 test cases，也寫了一些包裝過的 utility，期望讓大家寫 unit test 時不要有沮喪的感覺。

從目前的狀況看來，我們只是「有」了 unit test，但是我們還沒有思考覆蓋率，或是維護的問題，持續改善這一部分將是我們要繼續努力的地方。好消息是，我們的 CI 已經整合了 unit test 的部分，這多多少少也會鼓勵大家寫 unit test。只有當 RD 覺得 unit test 很好用時，他們才會願意花時間且認真的撰寫 unit test。我本人也不例外 XD

很久很久以前，當我還是一個小小的組長時，曾經努力地推過 TDD，也努力地要求成員們能夠為寫出來的 code 加上單元測試。那時候還特別開了一次會，找所有的人一起討論各種 domain 的程式應該怎麼進行測試。很遺憾地，那一次的努力以不了了之告終了。現在在我們還在 release 的軟體 source tree 裡頭，還躺了不少的 unit test 程式碼。那一次的推動，讓我有了一個感想，那就是在台灣，要推廣寫程式的人自己寫單元測試，看起來是不可行地。於是我的想法開始往另一個面向偏轉：一個人寫 code，一個人寫測試。

幾年過去了，我們現在的組織裡也有了專門寫程式進行測試的人，可是開發者與撰寫測試的人數比卻是接近 15:1。可以想見，大部分的程式是無法被包含在內地，只能挑選重要的模組進行單元測試補強。

而最近剛好有機會買了 Google 軟體測試之道。這一本書的名氣應該不如 Google 模式，但我覺得他對我的啟發要勝過 Google 模式。原因很簡單，要找到好的人才的道理大家都懂，但你得先有好的條件與環境才能夠吸引夠好的人。好的條件與環境除了薪資優渥、公共設施壯觀、擁有自己的餐廳...等管理處可以幫忙的事情外，我覺得更重要的是要讓成員有引以為傲的感覺。這種感覺來自他所從事的事情是不是夠有效率、是不是夠酷。夠酷的事情才是他們願意拋頭顱灑熱血(誤)的動力所在。Google 模式裡頭提到很多夠酷的措施，但我讀了 Google 軟體測試之道後才明白，快速才是 Google 的制勝之道，擁有了讓對手聞風喪膽的速度，就是一種酷。

而這種快速，所憑藉的是品質保證。每當你做一個修改，能在最短的時間知道對於原有系統有沒有負面的影響，這時候你就敢於修改。傳統上我們在面臨軟體 deadline 時會有兩種態度。一個是初出茅廬的團隊，因為初生之犢，所以無所恐懼，該改就改，但也陣亡很快。所以最終通常以熬夜做收。另一種則是久經沙場的老將，在 deadline 來臨前，會對任何修改有無限的恐懼，因為他的記憶裡浮現了一幕幕過去的慘痛經驗。想想看如果今天當你做完修改後 10 分鐘內就會知道有沒有改出 side effect，你還需要戰戰兢兢嗎?

Google 軟體測試之道所談的就是這樣的概念，它闡述了 Google 如何由草創期的傳統測試手法，進步到今天的高度自動化測試。高度自動化有多高呢? 在這本書的序裡頭提到，Google 每天都會在幾百萬的原始檔裡頭測試，並釋出幾億行的原始程式碼。每天，數十億次的建置動作推痛在數十萬個瀏覽器實體上所執行的幾百萬次自動測試。以 Google 目前 2 萬人的規模，等於一個人平均每天有 100 次以上的自動測試。你的團隊平均值是多少呢?

Google 一開始也不是就有今天的樣子，一開始 Google 在工程部只有 1000人，僅有 50 人全職的測試團隊。這個團隊被稱為測試服務，主要的工作是 UI 驗證工作。看起來跟公司的 DQA 部門的專長很類似。後來當 Google 的業務成長到不只是搜尋與廣告，測試工作變得複雜了，於是原來的測試做為不夠用了，他們開始尋求改變。

第一個改變是，測試的人也必須會寫程式。這個容易些，因為 Google 的招牌是蠻好用的，他們可以順利找到人，不過有一度，好的測試者，不久後就會被拉到開發團隊，因為 "可以創造的貢獻會更多"。要解決這個問題，他們的測試頭，開始思考，應該讓整個團隊都為品質負責，才能改變風氣，測試才不會在組織裡只是陪襯的角色。可想而知這樣的改變，在 RD 內部遭遇到強大的抗拒，因為工程師覺得他們受到威脅，一種必須在測試工作裡頭扮演更重大角色的焦慮感。那個頭頭卻有著驚人的執著，因為他覺得 "Google 是一家專注在創新上的天才們所建造的公司，而這種企業形象就是與漫長的產品推行週期不相容"。而且 "隨者使用者人數的快速增加，由臭蟲所造成的技術問題以及結構不佳的程式碼，將會終結這個程式設計師的樂園"。

所以他怎麼做? 從一個團隊開始，從工具開始做起，可想而知是前期面臨了重重的困難，尤有甚者，Google在那個時期因為業務的擴張，面臨強烈的測試人手不足，而更糟的是，他們併購的公司有幾家是所謂 rick & dynamic 內容的應用程式公司，例如項 Youtube, Google Docs 等。而危機就是轉機，在當時的氛圍下，要純用手工測試顯得更加力不同心，所以他在推動上反而找到了施力點。慢慢地一些架構建立出來了，有些開發者感受到這接測試架構與測試準則所帶來的好處。

時至今日，Google 的工作裡頭，測試已經是每個開發者必須執行的工作之一。他們的測試共分為三類：大、中、小。跟 Google 一向的原則類似，定義簡單明瞭。小測試就是單元測試，是由開發者自己行撰寫，採用假資料(mock)，主要驗證程式碼的流程與錯誤處理邏輯。這部分是很關鍵地，因為通常錯誤的路徑在傳統的測試裡頭都是最後被測試到的，但常常在最後關頭卡住出貨，小測試通常在幾秒或更短時間就會測完。

中測試也是常以自動化進行，主要牽涉到兩個或更多函式間的互動，一般稱為整合測試。在 Google 是由 SET 也就是開發者以外的人"推動"，但還是由 SWE 也就是開發者撰寫這樣的測試 (開發者很辛苦地 XD)。這類測試是自動化測試的核心，大部分時間再跑的是這類測試。在後續開發循環當中，這些測試也可能會被手動執行，隨時確保城市的品質。中測試的環境可能是模擬或者真實。

大測試則會涵蓋三個或更多功能，一般來說都是在真實的環境與資料中驗證。可能需要數小時甚至更久的時間。大型測試要處理的是"產品有沒有以使用者可以預期的方式產生期想要的結果?" 通常就是整個產品跑起來運行時的測試。這類測試仍需要 SWE、SET 等幫忙寫自動化組件。所以你可以發現，SWE 基本上需要參與所有測試的過程。

是不是所有東西都自動化，答案當然是不可能，但是可以利用錄製技術將相當程度的手動轉成自動或半自動。這些努力都有助於後續在軟體進行回歸測試的時間節省。

這本書的很多篇幅在介紹 Google 內的人員編制與責任工作，跟一些人的訪談，我覺得不容易歸納，不過光上面所提的一些重點，我覺得就受益良多了。



最後回到開頭的故事，最近我們在導入新的流程，也看了不少書，我慢慢了解之前失敗的原因了，因為單純的單元測試起不了作用，沒有環環相扣的自動化架構配合，不容易看出效果，所以當工程師看不到效果，就不會執行那多出來的工作了。

我們的自動化架構已經ready了，把你的架構建出來吧!