很久很久以前，當我還是一個小小的組長時，曾經努力地推過 TDD，也努力地要求成員們能夠為寫出來的 code 加上單元測試。那時候還特別開了一次會，找所有的人一起討論各種 domain 的程式應該怎麼進行測試。很遺憾地，那一次的努力以不了了之告終了。現在在我們還在 release 的軟體 source tree 裡頭，還躺了不少的 unit test 程式碼。那一次的推動，讓我有了一個感想，那就是在台灣，要推廣寫程式的人自己寫單元測試，看起來是不可行地。於是我的想法開始往另一個面向偏轉：一個人寫 code，一個人寫測試。
幾年過去了，我們現在的組織裡也有了專門寫程式進行測試的人，可是開發者與撰寫測試的人數比卻是接近 15:1。可以想見，大部分的程式是無法被包含在內地，只能挑選重要的模組進行單元測試補強。
而最近剛好有機會買了 Google 軟體測試之道。這一本書的名氣應該不如 Google 模式，但我覺得他對我的啟發要勝過 Google 模式。原因很簡單，要找到好的人才的道理大家都懂，但你得先有好的條件與環境才能夠吸引夠好的人。好的條件與環境除了薪資優渥、公共設施壯觀、擁有自己的餐廳...等管理處可以幫忙的事情外，我覺得更重要的是要讓成員有引以為傲的感覺。這種感覺來自他所從事的事情是不是夠有效率、是不是夠酷。夠酷的事情才是他們願意拋頭顱灑熱血(誤)的動力所在。Google 模式裡頭提到很多夠酷的措施，但我讀了 Google 軟體測試之道後才明白，快速才是 Google 的制勝之道，擁有了讓對手聞風喪膽的速度，就是一種酷。
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 內的人員編制與責任工作，跟一些人的訪談，我覺得不容易歸納，不過光上面所提的一些重點，我覺得就受益良多了。
最後回到開頭的故事，最近我們在導入新的流程，也看了不少書，我慢慢了解之前失敗的原因了，因為單純的單元測試起不了作用，沒有環環相扣的自動化架構配合，不容易看出效果，所以當工程師看不到效果，就不會執行那多出來的工作了。