Google 花了五年才讓工程師寫測試——Rainbow of Death 與 Cynefin 的交會

前 Googler Mike Bland 有一場演講，講的是他和一小群「煽動者（instigators）」如何在 2005 到 2010 年間，把自動化測試從沒人理會的邊緣實踐，變成 Google 全公司的標準開發文化。整整五年，而且大部分時間裡，他們並不確定會成功。

這個故事我反覆看了幾次，因為它幾乎是一個完整的 Cynefin 案例：一群人一開始把複雜（Complex）問題當成繁雜（Complicated）問題來解，撞牆兩年，之後改用探測（probe）的方式前進，最後才讓整件事沉澱成清晰（Clear）領域的標準程序。以下先把故事講完整，再談 Cynefin 能從中看到什麼。

起點：一個沒人跟進的成功經驗

Bland 的第一份工作遇上 death march——在脆弱、幾乎沒有測試的程式碼基礎上，被要求用不可能的期限交付不可能的功能。勉強交付後，他偶然在書店讀到一篇 unit testing 的文章，用在重寫子系統上：

每寫一個 function 或 class，就用快速、聚焦的測試徹底驗證，而非等整個系統組起來才看能不能動
新子系統讓整個系統快了 18 倍
bug 從發現、重現、修復、驗證到出貨只要一天，當年業界標準是下週、甚至下個月

有趣的是：隊友都認可他的能力，卻沒有任何人跟著採用測試。他想不通為什麼——這個困惑，成了後來五年的起點。

2005 年的 Google：什麼都好，就是沒人寫測試

當時的 Google 文化已經相當健全，code review、style guide、Tech Talk、知識分享都是標準配備。但幾乎沒有工程師寫 unit test，原因有好幾層：

教育缺口：MIT、Stanford 的資工研究所當時根本不教 unit testing
缺乏切身經驗：多數人沒經歷過 death march，沒有理解測試價值的經驗基礎
公司太成功：股價一直漲、人一直進來，很難主張「缺乏測試正在傷害公司」
數據文化反成阻礙：Google 的決策建立在數據上，偏偏「投資學測試會有回報」無法事先用數據證明
時間折現（temporal discounting）：現在出貨的回饋是立即的；學測試的工具又慢、回報遙遠又模糊。立即的痛苦加上不確定的效益，讓做對的事比它應有的難度高太多

檯面下，程式碼規模和複雜度正在爆炸，開發運作已經開始崩解。最好的反例是 Google Web Server（GWS）團隊——跑 google.com 首頁的伺服器。Tech lead Bharat Mediratta 採取強硬路線：

沒有自動化測試的變更一律不收
建立 continuous build，虔誠地保持綠燈
覆蓋率只能升不能降，政策對內部成員與外部提交者一體適用

政策不受歡迎，但團隊撐住後成為全公司生產力最高的團隊之一：能整合大量內外部變更、維持快速發布，新人因為測試覆蓋良好而能很快做真正的工作。問題是，GWS 只是大公司裡的一個小團隊，它的成功故事被 Google 的「標準敘事（standard narrative）」淹沒了。

Rainbow of Death：跨越鴻溝要做的六件事

Bland 借用《Crossing the Chasm》的採納曲線——instigators（創新者與早期採用者）、early majority、late majority、laggards——再疊上朋友 Albert Wong 提出的模型，取名 Rainbow of Death。它列出 instigators 要讓變革跨過鴻溝，必須做的六件事：

功能	內容
Intervene	專家親自下場：寫工具、遇到重大問題捲起袖子修
Validate	建立衡量進度的方式，讓 early majority 看見自己在進步
Inform	教大家用對的方式、為對的理由做對的事
Inspire	描繪願景：等大家都這樣做，世界會多好
Mentor	建立關係與社群，提供一對一的建議與 coaching
Empower	Early majority 自己成為專家，不再需要 instigators

兩個重要維度：

從左到右，是從「依賴專家」走向「自主獨立」，也是從硬技術能力走向人的能力
過程並非線性：他們是東做一點、西做一點，事後放進框架，才看出散落的行動其實在互相增強

五年行動時間軸

組織形式：2005 年成立 Testing Grouplet——用 20% time 運作的志工團體，幾乎沒有預算、零權力，但有嘗試瘋狂點子的自由，以 GWS 經驗為範本。

2005：主攻 Inform，結果撞牆

和內部訓練組織合作：Codelabs 練習頁、新人（Noogler）課程、Tech Talks、送免費書
發明新術語 Small / Medium / Large Test：因為當時名校畢業生對 unit test 的定義是「五分鐘內跑完的都算」，更久的叫 regression test。用新詞甩掉舊包袱，才能嚴謹定義每種測試是什麼、適合做什麼
與工具團隊合作，開始拆「我沒時間測試」的藉口

結果：大家聽完課、拿了書，還是不寫測試。Bland 的結論很誠實——光靠資訊與事實，改變不了人的世界觀與行為。但這一年幫他們發展出清楚的訊息與語言。

2006：Testing on the Toilet 與 Test Certified

先講一個失敗的嘗試：啤酒冰淇淋聚會聊測試——很好玩，沒效果。真正的突破是：

Testing on the Toilet：每週一期貼在廁所隔間的測試電子報，趁大家沒別的事可做時，一次灌輸一點知識。這份電子報從 2006 年發行至今。後來人們引用它就像引用官方 style guide：「我在廁所想到你的 code，你真該試試這招」
Test Certified：三級認證路線圖，解決「想做但不知從哪開始」。兩個效果：一是駭進 Google 熱愛量化績效的文化，二是明確告訴團隊從哪開始、如何前進，並配置 mentor 提供 coaching 與各級認證
Test Mercenaries：內部顧問團隊，進駐專案數月實作技術與工具，以 Test Certified 為指南與目標，同時把新工具用在困難專案上即時回饋，加速工具創新
Build Orbs：會發光的玻璃球，綠色代表 build 通過、紅色代表失敗。人們對球產生情感依附（「球不開心了，快讓它變綠」），紐約辦公室甚至做了自由女神像版本，火炬就是建置指示燈
Fixits：志工發起的修復日，全公司花一天做「重要但不緊急」的事——寫測試、修壞掉的測試、爬認證階梯。每辦一次，測試意識與採納就上一個台階

2007：統一使命

各行動開始各自為政，於是定出共同目標：兩年內讓所有專案達到 Test Certified Level 3。真正的意圖是達到 tipping point——讓所有專案「像 Level 3 那樣運作」，名義上有沒有認證無所謂。

這也給了測試工程師一個與開發者協作的框架：開發者把自動化測試做在前面，測試工程師就不用一直回頭報「你又寫了個蠢 bug」，而能提供更高價值的輸入——使用者體感、效能特性，這些人類擅長的事。

2008/1/31：Revolution Fixit，補上 Empower

他們發現 Rainbow 的 Empower 端很弱——多數人根本用不到好工具。這次全公司修復日推出雲端建置基礎設施，不必再在自己工作站上建置與測試。但要享受新工具，團隊必須先修兩件事：

清理到處都是、早已不需要的依賴
把所有 build inputs 簽入版控（當時 repo 越來越慢，大家把東西塞進 NFS filer 而非簽入 Perforce）

清完之後一切變快，「以前沒時間學的，現在突然有時間了」。「我沒時間測試」這個藉口，第一次被打出一個大洞。而且不是所有人都參加了 Revolution，但所有人都被影響——走廊上到處聽得到「我們這週要 revolutionize 我們的 build」。

2008 金融危機：意外的驗證

Google 沒裁正職，但裁掉大量承包商，其中多數是手動測試人員，還有不少 Test Mercenaries。然後呢？沒有品質危機。沒有 bug 滿天飛，開發速度照舊。Bland 認為這證明已達 tipping point：夠多人知道對的事是什麼、有能力做，而且做對的事已經夠容易。

2010：TAP 完成築橋

**TAP（Test Automation Platform）**成為全公司的集中式持續整合平台：

TAP 之前：各團隊自己維護 flaky 的 continuous build，壞了要 binary search 找兇手
TAP 之後：build 壞了，打開 TAP 就看到是哪個變更弄壞的；點進 code review，通常已有十幾個人跳進去，作者不是修好就是已 rollback

之後幾乎每個團隊都有通過中的 continuous build，互相課責，弄壞別人的 build 逃不掉。五年後的 2015 年，Google 工具團隊的 Rachel Potvin 在 @Scale 演講〈Why Google Stores Billions of Lines of Code in a Single Repository〉中明確說：沒有 TAP，這個單一 repo 的模型會徹底崩潰。

從 Cynefin 看這五年

現在把 Cynefin 的鏡頭架上去，有五個地方值得細看。

1. 問題在 Complex，前兩年卻用 Complicated 的方式在解

Complicated 領域的假設是：因果關係存在，只是需要專家分析（sense–analyze–respond）。所以早期策略是「大家只是不知道，把知識給他們就好」——開課、演講、送書。結果無效。

測試採納牽涉到世界觀、同儕壓力、時間折現、工具體驗，因果只有在事後回顧才看得清——這正是 Complex 領域的特徵：你無法事先分析出正確答案，只能 probe–sense–respond。Bland 自己說得很直白：他們摸索了兩年才拼出大願景，「如果一開始就等著先有大計畫，大概什麼都做不成」。這句話放在 Cynefin 裡，就是在 Complex 領域拒絕預先設計完整解方。

2. 那一堆行動，就是一組 safe-to-fail probes

啤酒冰淇淋聚會、廁所電子報、認證制度、發光球、Fixit——每一個都成本低、失敗了不傷筋骨
啤酒聚會失敗，讓它淡出（dampen）
Testing on the Toilet 意外奏效，持續放大（amplify），一發十幾年

這是教科書等級的探測管理：同時跑多個探測，觀察哪個產生正向模式，放大有效的、抑制無效的。他們當年不知道 Cynefin，但行為完全吻合。

3. 標準敘事是既有的吸引子，要動的是約束條件

「標準敘事」在 Bland 口中，指的是我們照常營業時走的那些流程，伴隨著對下游後果不完整的認知。用複雜系統的語言講，這是一個很深的吸引子（attractor）盆地：直接出貨的回饋立即，寫測試的回報遙遠，系統自然滑向不測試。

對付吸引子，說教沒有用，要動的是約束條件與能量梯度：

Revolution Fixit：把建置搬上雲端、強制清理依賴，讓「做對的事」的成本大幅下降——梯度一改，行為自己流過去
GWS 的「沒測試不收 code」：治理型約束（governing constraint），劃出硬邊界
Test Certified：更接近賦能型約束（enabling constraint），給方向但留下各團隊自己走的空間
Build Orb 與 TAP：即時回饋迴路，把原本遙遠模糊的後果拉到眼前

這一整套，比任何一場 Tech Talk 都更能撼動吸引子。

4. 變革的終點，是把實踐從 Complex 護送到 Clear

早期探測在 Complex 摸索出有效模式
Test Certified 把模式整理成路線圖，進入 Complicated——有專家、有方法、可以照著走
TAP 上線後，continuous build 變成人人都有、互相課責的預設，落進 Clear，成為 Kurt Lewin 說的 refreeze

Bland 引用 Lewin 的 unfreeze–change–refreeze 描述這段歷程，Cynefin 補上更細的地圖：unfreeze 和 change 發生在 Complex，refreeze 是實踐向有序領域的遷移。順帶一提，落進 Clear 也有風險——Cynefin 提醒過，Clear 緊鄰混亂的懸崖，當年的最佳實踐若不再檢視，哪天環境變了就會摔下去。

5. 最難的部分：死掉的是自己的想法

Rainbow of Death 的 death，Bland 到後來才想通指的是什麼——是 instigators 自己的想法與 ego 的死亡。每次看到沒有測試的 code review 被放行，他都想衝上去搖醒對方：「你知道你在做多危險的事嗎？」但他忍住了，因為：

指標和論證改變不了大多數人的心，經驗才可以
你的工作也包括放下對別人的評判，去理解真正的痛在哪裡
你想解決的問題，可能不是你必須先解決的問題

這和 Cynefin 社群常談的 entrained thinking 完全同構：在 Complex 領域裡，最大的風險來源經常是介入者自己的既有框架。Bland 用 Caravaggio 的《大衛與歌利亞的頭》收尾——那顆被砍下的頭，是 Caravaggio 的自畫像。阻礙變革的巨人，很多時候長著我們自己的臉。

給正在導入變革的人

如果你正在組織裡推 AI coding、推測試文化、推任何需要跨越鴻溝的實踐，這個故事提供幾個可操作的檢查點：

你現在的做法，是在 Complicated 的假設下開課送書，還是在 Complex 的假設下跑多個小探測？
你有沒有機制去放大意外奏效的探測、讓失敗的安靜退場？
你動的是人的觀念，還是行為背後的約束條件與回饋迴路？
Rainbow 的六個功能——Intervene、Validate、Inform、Inspire、Mentor、Empower——哪一塊現在最薄弱？
在選擇跟隨標準敘事、或走自己的路之前，你還能等多久？

Google 那群人花了五年，前兩年還在瞎試。這對我們反而是個安慰：探測期的混亂並非做錯了什麼，它就是 Complex 領域該有的樣子。

演講來源：Mike Bland, “The Rainbow of Death” https://www.youtube.com/watch?v=V4YtwuVbaJA