來源：HuangLi@SDET
前言：經過前兩篇的介紹之後，評論裡留下許多問題。並沒有逐一回復，當然不是想把這些評論置之不理，而是希望在這裡和後面的文章中做詳細介紹和解釋這些問題。從這一篇開始，我將開始講谷歌是如何測試軟體的了。
在谷歌，質量不等於測試，是的，我確定在其他所有的公司也都是這樣。“質量不是被測出來的”，這句陳詞濫調是再正確不過的了。不管汽車製造還是 軟體開發，如果在最初的設計建造的時候就有問題，那它永遠都會有問題。試問任何一家曾經被迫大量召回汽車的公司，逃避質量問題的代價是多麼的昂貴。
但是，“質量不是被測出來的”這句話本身並不像它聽起來的那麼簡單和準確。雖然質量並不是被測出來的，但同樣也有證據表明，未經過測試，也不可能開發出有質量的產品。你連測試都沒有做過，又是怎麼知道產品功能是否正確，並有高質量呢？
對於這種難題，最簡單的辦法是不要區分開發和測試，不要把他們當成對立的活動。測試和開發【譯註：兩種行為，不是人】最好能手牽手的並行，寫一點 程式碼就立刻進行測試，寫的越多，測的就要越多。最好是，在編碼的同時，甚至在編碼之前，就考慮清楚這些程式碼將如何被測試。測試不是一個單獨的工作，測試就 是開發的一部分。所以，質量並不等同於測試，當把開發和測試混在一起，攪拌直到分不清他們彼此的時候，就得到了質量。
這就是谷歌的想法，把開發和測試工作混在一起，不分彼此。寫點程式碼，就必須測試，多寫一些就多測一些。關鍵的問題就是誰來做測試工作？ 由於谷歌的專職測試人員非常的少，唯一的答案就只能是開發人員。還有比實際寫程式碼的開發人員更適合來測試這些程式碼的人嗎？還有比程式的作者更懂得怎樣去發 現程式 bug 的嗎？是誰更想知道程式在第一次執行時是否有沒有問題呢？谷歌之所以用這麼少的專職測試人員的原因就是開發對質量負全責。實際上，如果一個團隊在過於依賴 測試的時候，通常情況下這個團隊在開發上一定也會有問題。如果在這個團隊裡，測試人員比較多，這也是一個強烈的訊號，這表明開發和測試融入到一起的程度還 不夠，失衡了，缺乏測試，單純地增加測試人員並不能解決任何問題。
這意味著，對於質量來說，預防問題比發現問題本身更重要。質量是開發人員的問題，而不是測試人員的問題。通過把測試工作融入到開發過程中，我們 能降低那些富產 Bug 的人的出錯機會，不僅可以避免了大量終端使用者的使用問題，而且還可以極大地降低測試人員報無效 Bug 的數量。在谷歌軟體測試工程師的工作目標就是檢查這種預防措施是否有效，軟體測試工程師不停地尋找一些證據來證明作為 bug 的作者和預防者的“軟體開發工程師-軟體測試開發工程師”組合是否存在問題，一旦發現任何不正常，就會拉響警笛。
這種開發和測試一體的場景隨處可見，不管是在程式碼稽核的時候問“你的測試呢？”，還是在廁所蹲坑裡張貼著的最佳測試實踐–臭名昭著的馬桶測試指南【譯者注，參見 google test blog，有關於”Testing On The Toilet“的更多介紹】。測試是開發過程中必不可少的一環，質量是開發和測試合體的產物。軟體開發工程師，軟體測試開發工程師，軟體測試工程師，所有 的人都是測試人員。
如果你所在的公司也想要做這種開發和測試的統一，請也給大家分享一下其中經驗和教訓。如果沒有，這將是一個幫助你公司的機會：讓開發和質量劃等 號。你大概知道諺語裡說的，雞和豬為了一頓有培根和雞蛋的早餐都樂於奉獻自己，但是豬卻犧牲了。好吧，這就是事實，嘗試跑到開發工程師那裡，對他們”哼哼 “（豬叫聲）兩聲，看他們是否也用”哼哼“來回應，如果他們”咯咯噠“（雞叫聲）來回應，那就說明有問題了。
【譯者注，崩潰了，這裡比較難懂。James 這裡引用了一個豬和雞的英語諺語，（參見，http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig ），諺語的意思大概是，豬和雞都參與制作培根雞蛋早餐，豬變成了豬肉（培根），雞隻下了一個蛋，說明對於早餐，豬和雞的奉獻程度是不同的。並在這裡把測試 工程師比喻成雞，開發工程師比喻成豬，早餐就是質量，豬的奉獻大。測試人員跑到開發人員那裡，如果發現他們沒有做豬的事情，早餐將做不成，那說明質量也將 會有問題。】
【四】
爬，走，跑。
在比其他公司少很多測試人員的情況下，谷歌做的還不錯的一個關鍵原因是，很少嘗試在一次釋出中包含很多的功能。實際上，谷歌經常反其道而行之， 在一個產品的核心模組被開發後，如果有一定數量的受益人群就立刻釋出，然後不斷的得到使用者反饋再迭代開發新功能。這也是我們在 Gmail 上的做法，Gmail 被貼上 Beta 版本的標籤線上上運營了四年。通過這個 Beta 標籤也可以來警示使用者，Gmail 還並非完美的產品，有出錯的可能。只有當郵件資料達到 99.99% 的時間都是可用的時候，我們目標就算達到了，這個 Beta 標籤才會被去除。很明顯，質量是一個不斷改進的過程。
這裡的這個改進過程，並不像西部牛仔那樣，一下子什麼都能搞出來。實際上，一個產品為了達到我們稱之為 Beta 的版本，也要經歷一系列的過程，並在過程中證明其價值。Chrome 是我加入谷歌前兩年一直所工作的團隊，它同樣經歷了多個版本。在每個版本里，基於對產品質量的信心和不斷尋求的客戶反饋才讓我們進入到下一個版本。這些版 本歷程大致如下：
金絲雀版本（Canary Channel），不太可靠的版本，並不適用於釋出。就像一隻金絲雀在煤堆裡一樣，如果不幸身亡，那說明還有工作要去做。只有超強容忍能力的使用者才有可能使用金絲雀版本來試驗執行，你不能依賴這樣的應用能把實際工作完成。
開發版本（Dev Channel)，是開發工程師們日常工作中使用的版本。所有的同一產品組的工程師都需要去安裝這個版本，並在真正的工作中使用他們。
測試版本（Test Channel），是給內部的狗食，如果能夠有持續不錯的效能表現的話，也可能會是 beta 版本的候選。【譯者注，dog food，一般指自己團隊的產品，給自己或者公司內部的人嘗試使用的中間產品】
Beta 版本或釋出版本(The Beta Channel or Release Channel)，是給外部使用者使用的第一個版本。只有在之前的各種版本歷程中通過了測試和真實使用者的槍林彈雨般的驗證後，才會成為 beta 版。
上述的這種從爬到走、走到跑的模式，讓我們在執行一些測試同時又可以對我們的應用系統做一些試驗調整，並從真實使用者和每個版本的每日自動化測試那裡得到及時的反饋。
對於這樣的過程，還有一些分析角度的益處。例如，發現了一個 bug，測試人員可以根據這個 bug 建立一個測試用例，並針對所有的每一個版本都執行這個測試用例，從而可以驗證這個 bug fix 是否在所有的版本中都真正得到了修復。
【譯者注：關於 Chrome 與 Chrome OS 各版本的稱呼，可以參見 http://www.chromi.org/chromedownload ，其中也涉及到本文中各個版本的稱呼，但並不是與 James 文中完全一致，實際上像金絲雀版本，一些喜歡嚐鮮的外部使用者也在使用】
By James Whittaker
●How Google Tests Software – Part Three
●How Google Tests Software – Part Four