James Whittaker是Google的測試總監，曾任微軟構架師，也是“實用軟件測試指南”系列圖書中好幾本書的作者。他最近寫了一系列的博文，介紹Google是如何進行測試。Google把開發和測試緊密結合在一起，測試人員相對較少，每個產品在正式上線前都要經過好幾個不同的版本。
Google保證產品質量的方法和很多公司是不一樣的。Google沒有一個龐大的測試部門，相反，部分測試工作委派給了開發人員。Whittaker寫道：
測試和開發同時進行。編寫一些代碼，馬上進行測試和構建。接著，編寫更多的代碼，繼續測試。更好的是，在你編碼的時候或者編碼之前，就計劃好你的測試。測試不是一個獨立分開的過程，它是開發的一部分。質量不等同于測試;要想有高質量的產品，就要把開發和測試緊密捆綁在一起，直到不分彼此。
這是因為，Google認為要保證質量，預防勝于檢查：
質量來自開發，而不是測試。為了拓寬開發環節，我們可以把測試融入到開發中去。我們已經建立了一個超高效的增量流程，只要有一個增量被證明缺陷太多，我們就可以回滾這些錯誤。我們不僅預防了很多產品級問題，還大大地減少了那些為確保消除“召回級別”缺陷而安排的測試人員的人數。
因此，在Google，測試人員不用做測試是眾所周知的，他們只要“確保他們【開發人員】有自動框架和相關流程”進行測試即可。開發人員進行必要的測試，他們對他們的代碼質量負責。這其實就是強調了一點：“質量的重擔落在那些負責交付正確產品的開發人員的肩上�！睘榱藢崿F他們的質量哲學，Google有三種類型的工程師，Whittaker解釋道：
SWE或者軟件工程師是傳統的開發角色。SWE編寫最終交付給客戶的功能代碼。他們編寫設計文檔，設計數據結構以及整體架構，花絕大部分時間編寫和審查代碼。SWE會編寫很多測試代碼，包括測試驅動設計，單元測試，以及在未來的幾篇博文中我們會具體解釋的，如何參與到簡單、中等甚至復雜的測試集成中去。SWE們對他們參與的一切的質量負責，不管是他們編寫的、修復的或者是修改的。
SET或者測試軟件工程師(Software Engineer in Test)也是開發角色，只是他們專注于易測性。他們審查設計，密切關注代碼質量和風險。他們重構代碼，讓代碼更加易于測試。SET需要編寫單元測試框架和自動化測試。他們的代碼也會提交到SWE所工作的代碼庫(code base)，但是他們更加關注提高質量和測試覆蓋率，而不是增加新功能或者提高性能。
TE或者測試工程師則跟SET恰恰相反。他們這個角色會把測試放在首位，而把開發放其次。很多Google的TE會花很多時間來編寫模擬了實際使用場景甚至是模擬了用戶的自動化腳本和代碼。他們也整理SWE和SET的測試工作，解讀測試結果從而驅動測試，他們也會在項目后期參與到項目中去，來強力推動項目發布。TE是產品專家，質量顧問也是風險分析員。
換句話說，SWE負責軟件功能特性和它們的質量。SET提供代碼支持，從而使SWE能測試這些產品特性。TE快速地測試系統或者再次檢查那些被開發人員忽略的主要缺陷。并且，他們協助用戶測試，還進行性能、安全以及其他類似的測試。
在公司級別，Google有幾個關注域(Focus Areas)——搜索、廣告、應用程序、移動服務、操作系統等等。其中有一個關注域是工程生產力(Engineering Productivity，EP)，它包括了一些“橫向和縱向的工程規范(horizontal and vertical engineering disciplines)”，測試是其中最大的一塊。EP包括：
產品團隊——為整個Google的所有工程師提供能提高生產力的工具，包括開源項目，比如“代碼分析器、IDE、測試用例管理系統、自動測試工具、構建發布系統、版本控制系統、代碼審查安排系統、缺陷數據庫�！�
服務團隊——為任何Google員工提供關于可靠性，安全，國際化等領域的專業知識，包括“工具、文檔、測試、發布管理、培訓”等等。
派遣式的工程團隊(Embedded Engineers Team)——在Google，測試人員會被借調去不同的產品團隊。他們可以選擇為一個團隊服務很多年，但公司鼓勵他們去不同的團隊輪崗，從而能夠“在產品知識和新鮮視野之間”保持一個良好的平衡。這些測試人員參與到產品團隊中的很多不同的關注域，但是從組織關系上來說，他們匯報給EP管理層。這樣做的理由是能夠建立一個“讓測試人員共享知識和信息的論壇。好的測試想法在EP內部很容易傳播開來，從而使所有測試人員，不管他們為哪個產品服務，都能夠了解到公司內最好的技術�！�
這種測試策略帶來的結果就是相對較少的測試人員。根據Whittaker的觀點，這也可能是因為“我們很少嘗試一次快速交付很多功能。事實上，我們的目標恰恰相反：構建一個產品的核心部分，一旦它對很多人有價值，我們就發布這個產品，隨后我們收集反饋，繼續迭代�！绷硗庖粋�確保質量的關鍵元素是使用多重版本。Whittaker以Chrome為例，介紹了四種不同的版本：
金絲雀版(Canary Channel)——還沒有做好發布準備的代碼
開發版——開發人員使用的版本
內部測試版(Test Channel)——為了準備beta發布的版本
測試(beta)或者發布版——這個版本的產品可供Google內部或者公眾使用。
產品發布以后，如果發現了一個缺陷，我們會編寫一個測試，并且在所有的版本中進行驗證，看看這個缺陷是不是已經在某個版本里面被修復了。
簡單來說，這就是Google用來測試他們的產品、確保代碼質量的流程和組織結構。
文章來源于領測軟件測試網 http://www.k11sc111.com/
