原創翻譯，請勿轉載！！！！
（注：翻譯這部分Blog文章的初衷有兩點，第一，這部分blog作爲書google測試之道的起源，裏面的內容有部分被書中捨棄的；第二，網上很多流傳翻譯版本，不足以合胃口）
此篇Blog是系列文章的開篇。
我被問得最多的一個問題是“Google是怎麼測試的”，接下來我會零零碎碎地回答這個問題，之後也會持續更新。我這一系列的文章，既談到了我們現在做的，也有我們未來要發展的方向。
1、產品團隊：負責公司內部使用的和開源工具的開發，包括代碼分析工具、IDE、測試用例管理工具、自動化測試工具、編譯工具、編譯系統、代碼版本控制系統、代碼評審工具、Bug數據庫等。這些工具會讓工程師的工作更加的高效。比起用來發現錯誤，工具在預防錯誤上更具有戰略意義。
2、服務團隊：爲上述產品團隊開發的各種工具提供最大支持，包括工具、文檔、測試、發佈管理、培訓等等，也涵蓋了穩定性、安全性、國際化，同時也給生產團隊解決特定產品的功能問題。
3、注入工程師：它可被外借到Google的產品團隊中。有的工程師可能在一個產品團隊一待就是好多年，有的工程師會輪換到最需要他們的團隊中去。Google鼓勵工程師在產品團隊中切換，這可以保持工作的新鮮感、濃厚的興趣和立場的客觀。測試人員並沒有什麼不同，但是切換團隊的步調由測試人員自行掌握。比如我所在的Chrome團隊，有些工程師待了很多年，有些加入有18個月了。還有些已經離開。如何在產品穩定性與注入新生活力之間保持良好的平衡，是測試經理需要高度關注的點。
這種測試組織方式就意味着測試人員屬於一個產品團隊，如搜索引擎、Gmail或Chrome，但卻直接向EP經理彙報工作，他們身在產品團隊，參與計劃、日常工作、分享獎金、被其他團隊成員完全當成組員並獲得信任。這種彙報模式分離方式的好處，就是給測試人員提供了分享信息的平臺。不論測試人員身處哪個產品組，好的測試理念都會很容易在整個EP中推廣，並讓公司能獲得最好的技術。
這種項目和工作彙報分離的模式，也是有風險的。目前爲止，最大的風險就是，測試人員是外部資源。產品團隊不能把測試人員放到很重要的位置上，但同時又必須保證產品的高質量。是的，這是正確的：在Google，產品團隊對產品質量全權負責，而不是測試人員。每一個開發人員都被希望能進行自我測試。而測試人員的工作是確保產品團隊有自動測試框架，並能實施下去。測試人員就是“驅動開發人員來測試的”。
我喜歡這種研發模式，它能把開發和測試人員放到平等的位置上，讓整個團隊在產品質量保證方面站在了同一戰線上。另一個好處就是，它讓開發與測試比例，爲多對一。開發人員多於測試人員，在測試方面，他們就會做得更好。產品團隊應該爲這種高比例而自豪！
我想你們已經發現了這種模式的一個漏洞。開發人員是不能測試的！是的，我能否認這個嗎？
Google對這一問題的解決方法是，分離角色。在Google，我們有不同類型的測試角色，這是我下一節要談到的內容。
