How Google Tests Software (Picture From Amazon)

前言

一直以來，測試對工程師而言都是明明知道很重要，但就是不想做。
其實我也不例外，以前在交作業的時候，頂多多跑幾個測資，作業都快交不出來了，哪管的了這麼多啊…

總以為進公司後就是有專職的測試工程師幫你搞定一切，但實際上，QA主要都是以使用者角度出發，主要目標還是測整體的功能，比方說手機能不能上網打電話拍照之類的。
那說好的單元測試呢? 當然是個人造業個人擔啊!!

以實務上來說，從產品、組織架構、職務分工到程式語言每間公司一定都不盡相同，這本書的作法一定不可能無縫接軌套到別的公司，但他的概念一定是有值得學習的地方， 畢竟常常聽到FB/IG又當機多久或微軟有xx重大漏洞，卻很少聽到Google出什麼大包，以Google如此龐大規模來說，我覺得這非常不簡單!

Google有多大? 2016年的報導 How Many Lines Of Code Are There In Google, Facebook, And Windows OS 指出，Google可是有20億行的程式碼!!

而這本書就是在介紹「在Google的測試人員被賦予的任務是什麼，以及他們怎麼測試每天成千上萬筆改動」

有興趣的就一起繼續看下去吧!

這也算是我第一次嘗試讀整本原文書(沒辦法，中文書已經絕版了orz)，大部分內容都是以我個人的理解整理出來，如果有錯或不通順也請幫忙糾正!!

以下，正文開始~

Google連測試團隊命名都與眾不同

Google的QA Team叫做 Engineering Productivity，中文為工程生產率， Wiki 上對生產率的定義

生產率是有效運用創意和資源，提高產品和服務的附加價值，是某段時間內每一單位勞動投入所得的產量，以較少的資源投入生產出較多的產品即是生產率提高。

也就是Engineering Productivity團隊的人除了負責各產品的測試之外，也負責開發測試用的各種工具，從自動化的框架到模仿使用者點擊的行為的模擬器都有。

Google成功的秘訣為: 別雇用太多測試人員

這句話乍聽之下挺不直覺的，但仔細想想其實也很合理。在Google有各式各樣的專案，像Chrome / 搜尋 / 廣告服務 / 甚至到Android，如果每個專案都請專職的測試人員，那人數會非常可觀，所以他們反其道而行，讓開發人員利用Engineering Productivity提供的各種工具來分攤測試的責任，自己的UT是必要之外，有時候也需要加入大規模測試。

這點我認為如果測試的工具夠好用的話，開發人員寫測試就不會是太大的負擔，同時也提升不少Debug的效率，所以的確可以達到降低測試人力的目的。

品質不等價於測試 (Quality != Test)

我看到這句話的時候也是滿臉問號，整本書都在強調測試的重要，然後又說品質不等於測試!?

原來，作者要告訴我們，如果你的設計一開始就有瑕疵了，那即使透過測試證明他能動，也不代表他是個有品質的設計。

一開始就應該把設計做好，可以避免後續產生更多問題!

而測試應該是與設計相輔相成，目的在於讓我們對自己的設計更有信心，在透過各式各樣的考驗後，我們才有辦法說服別人這是一個有「品質」的設計!

角色 & 組織結構

Google的開發人員主要分為以下三種角色:

  • SWE (SoftWare Engineer) : 就是傳統的開發角色，幾乎所有時間都在寫程式，但如前面提到，這裡的程式其中包含自己功能的測試程式。

  • SET (Software Engineer in Test) : 同樣也是開發人員，也是幾乎所有時間都在寫程式，但不是為了新功能或程式效能，重點是擺在測試，如前面提到的各種測試工具以及模擬器。比較令人訝異的是他們甚至會為了方便測試而重構SWE的程式碼。

  • TE (Test Engineer) : 從使用者的角度來測試，接近其他公司的TE，但是有些TE也會寫自動化測試的工具。這本書給他們一個很潮的Title: “他們是產品的專家、品質的顧問、甚至是風險分析師!”。

而Google的開發人員所屬單位稱為Focus Area，類似其他公司的BU/BG的定位。這邊強調的是SWE與 SET/TE是分屬於平行的FA，也就是SET/TE是由Engineering Productivity的老闆來統一分配不同專案的人力，這樣做的好處有:

  • SET/TE並不受SWE的指派來做事(不用打雜)，可以發揮每個角色的專業
  • SET/TE可以透過指派不同專案，讓他們保持一定的新鮮感
  • SET/TE可以透過指派不同專案，將他們的經驗帶到每個不同的專案

翅膀硬了才能飛

在一開始提到，Google為什麼比較少出包，原因很簡單，因為他們很少一次在同一時間推出很多新功能，而是漸進式的一個一個來，確保前面沒問題之後才推出下一個功能，這樣做不僅能降低風險，同時還能有效的降低測試人員的數量，另外，還能透過收集使用者的試用回饋來決定他們下一步要怎麼做，好處超多啊!!

而他們是怎麼做到呢? 原來也不外乎就是透過Version Control依照不同的目的去切分以下的 Channel

  • Canary (金絲雀) Channel : 大家一定也跟我一樣好奇為什麼是金絲雀!? 原來是因為以前在挖煤的時候，礦工都會帶著金絲雀，他們對甲烷跟一氧化碳比較敏感，所以可以提前偵測到危險。也就是這個Channel的用途就是最前期開發，將實驗性質的功能放在這裡試跑及收集回饋同時debug。
    這應該類似線上遊戲封測的概念，比方說LoL就把新英雄或新地圖放在體驗服讓玩家試玩，如果有bug或技能太強就會馬上修正。 找了一下，Chrome就有Chrome Canary Project給進階玩家嘗鮮。 Google Canary

  • Dev Channel : 給開發人員做每日開發用，已經較穩定有通過一些基本測試。

  • Test Channel : 已通過大量測試。可以釋出給全公司或合作夥伴使用。

  • Beta/Release Channel : 通過所有測試且在試用中存活下來的Build，接下來可以準備對外Release。

小/中/大測試

Google直接將測試以涵蓋的範圍來分類，其中的差異就如下表。

Type 目標 出發點 誰來寫 自動化程度 跑單筆測資時間 測資數量 接近實際使用
Small Test 單一Function 開發人員 SWE 高 短 多 最不像
Medium Test 多個Function 開發人員 SWE 中 中 中 中
Large Test 功能/產品 使用者 SWE + SET + TE 低 長 少 最像

總結

第一章是核心概念的介紹也算是最精隨的部分，接下來會針對開發角色/Channel/ 測試做更詳盡的介紹。

希望我能有力氣把後面的章節都整理完!! 加油>_<