很久很久以前，當我還是一個小小的組長時，曾經努力地推過 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了，把你的架構建出來吧!