對於認真探究如何測試、改善測試效果的團隊和組織來說，研究業界大佬的測試和質保實踐，一定可以受益匪淺。

顯然，谷歌、微軟和亞馬遜這樣的公司，如果不是對產品質量足夠重視，是不可能像現在這樣成功的。

但是對軟體巨頭們的研究表明，成功並沒有放之四海而皆準的祕訣。讓我們一起來學習，世界上最著名的五家公司是如何組織他們的質量保證工作的。

谷歌：尋找最佳實踐

谷歌，這個世界上最大的搜尋引擎公司，是如何組織測試工作的呢？這要視產品和團隊而定。

舉個例子，負責搜尋引擎的團隊，維護了一個龐大又嚴謹的測試框架。因為搜尋是谷歌的核心業務，團隊想要保證持續地、高質量的交付，不希望因為測試工作不到位而把產品搞砸。

谷歌採用了一個四段式測試流程來處理搜尋引擎的改動：

1. 由專職的、內部測試人員（谷歌員工）進行測試；

2. 在眾測平臺上進行進一步的測試；

3. 自我試用階段，即由谷歌的員工在日常工作中來使用產品；

4. Beta測試，即把產品釋放給一小部分終端客戶來使用。

這樣看似完善的測試流程，谷歌前工程總監詹姆斯·惠特克在一段視訊中仍然解釋說，還有改善的空間——負責不同階段測試的人員之間的溝通還沒達到理想狀態（可能導致部分功能被多次測試或者漏測）。

但是，負責非核心產品的團隊採用的測試流程，則沒有那麼嚴格。有時，根本沒有專職的測試人員來為產品構建安全網，個別產品的測試工作完全由開發人員來完成。

無論哪種情況，谷歌都很認真地對待測試工作。事實上，谷歌的測試人員薪酬和開發人員持平，這在其他公司並不常見。

瞭解更多關於谷歌測試的資料，參考谷歌測試部落格-Google Testing Blog：http://www.googblogs.com/category/google-testing-blog

臉書：開發驅動測試

臉書不僱傭專職的測試人員。這個社交媒體巨頭依賴他們的開發人員去測試自己的程式碼（或者做互動測試）。

過去，這些測試工作都是手工完成的。現如今，臉書已經實施了各種自動化的測試方案。他們使用各種各樣的測試工具，從做後臺單元測試的PHPUnit，到Jest—一款由臉書內部開發的Java測試工具，再到做端到端測試的Watir。

與谷歌相似，臉書也用內部測試來保障軟體的可用性。並且，臉書有一個堪稱臭名昭彰的做法：把搞砸事情的開發者當作罪犯，給他戴上小丑的鼻子，拍照，發到內部的臉書討論組。

臉書已經意識到了他們的測試流程有明顯的缺陷，但是與其花很長的時間去改善，他們選擇接受這些缺陷，這印證了他們說的話——“社交媒體並非剛需”。此外，減少對測試的關注，意味著可以釋放更多的資源專注去做更有價值的工作。

相比於反覆測試軟體，臉書傾向於使用一種被稱為“金絲雀”的釋出方式。即，使用增量部署的策略，在生產環境上測試補丁、更新或者新功能。比如，一個新功能在最開始的時候只對一小部分使用者開放。

通過跟蹤新功能的使用情況和反饋，公司會決定是繼續擴大試用範圍還是禁止這個新功能，是進一步改進還是直接放棄。

亞馬遜：部署先行

與臉書相似的是，亞馬遜也沒有大量的專職測試人員。甚至曾有人暗示，亞馬遜的測試職位微不足道。亞馬遜的測試人員與開發人員的比例是1:7，這也說明了在亞馬遜，測試並不是一項重要的工作。

然而，亞馬遜公司本身並不這麼認為。對亞馬遜來說，測試與開發人員的比例只是一個輸出變數，並非輸入變數。換句話說，一旦公司意識到收入下降或者因為網站異常而導致客戶流失，公司就會追加測試的投入。

亞馬遜給人的感覺是它的開發和部署流程相當成熟（公司因每11.6秒釋出一個新版本而聞名），以至於並不需要大量的、詳盡的測試。

它所做的，是儘可能地把產品部署和出錯回滾變的簡單。這樣，即使發現任何錯誤，可以很容易將產品回滾到一個沒有問題的版本。

Spotify: 分隊，部落和分部Spotify僱傭專職的測試人員，他們隸屬於一些跨職能的團隊，每個團隊都有自己的明確使命。在Spotify，員工是按照已經小有名聲的Spotify模型來組織的。Spotify模型包括以下部分：· 分隊：一個分隊基本上就是一個Scrum團隊，分隊注重原則勝過注重實踐。Spotify有一句名言是這樣的“規則是良好的開端，但是該破則破”。一些分隊可能有多個測試人員，而另外一些分隊則可能一個測試人員也沒有，這完全取決於分隊的使命。

· 部落：隸屬於同一個業務領域的一組分隊的集合。屬於某個分隊的測試人員自然就從屬於相應的部落。

· 分部：為了促進員工相互之間的學習和經驗分享，Spotify用分部把分散在不同分隊和部落的、具有相同技能的員工組織到一起。

Spotify非常認真地對待測試工作。就像程式設計一樣，Spotify認為測試過程是富有創造性的，有些事情不能（或者不能全部）自動化。與另幾大巨頭相反的是，Spotify非常依賴它的測試人員去考察和評估其產品，而不是試圖把測試工作儘可能地自動化。

未來，Spotify的測試會是怎樣的呢？Spotiy的測試經理，同時也是基於模型的自動化測試工具GraphWalker的創始人克里斯蒂安·卡爾說：“未來，我們花在測試上的時間會和今天一樣多。但是，自動化測試工具以及自動化測試中獲得的資訊，將會使我們的測試工作變的不同”。

最後，一個事實是：為了最小化運轉裝置和維護測試環境的成本及消耗，Spotify的大量測試都是在生產環境上進行的。

微軟：測試者就是工程師

微軟當前的測試和開發人員的比例大致是2:3，與谷歌一樣，微軟付給測試人員的薪水與開發人員持平——除此之外，他們也不稱為測試人員，而是被稱為：測試領域的軟體開發工程師（或簡稱為SDETs）。

微軟的測試人員比例如此之高，是因為微軟的大量收益來自於那些交付給客戶並安裝在客戶電腦上的產品，而不是網站或者線上服務。

不管是因為缺陷還是新功能，更新這類產品都很困難（至少是非常令人討厭的）。因此，微軟投入了大量的時間，人力和財力去保證高質量地交付產品

從IT巨頭身上，我們能學到什麼

既然世界上最著名的五家科技公司在測試的文化、視角和流程上可以如此不同，這就說明了關於測試並沒有所謂的唯一正確的道路。

這五家公司分別制定了他們自己的測試流程，選擇了最適合他們的方法。而且五家公司都非常成功，他們一定是採取了適合自己的正確方法，不是嗎？

然而，我們還是可以從上述故事中學習到一些道理，從而應用到我們自己的測試策略中。

· 從“由專職測試人員為測試工作負責”到“人人都為測試活動負責”，測試的責任範圍其實是一個連續譜，在這個區間中選擇哪個模式要視團隊的技能而定。

· 測試重要性的範疇也是一個連續譜，從“未經測試的內容決不上生產環境”到“我們把所有內容直接放在生產環境上，如果有問題，直接在那裡測”。你的團隊在這個區間的哪個位置，取決於失敗帶來的風險以及問題發生後回滾版本和解決問題的難易程度。

· 自動化測試在上述五家公司中都有很重要的位置。雖然自動化實現的程度不盡相同，但是五家公司都使用工具來優化他們的測試工作，你或許也應該借鑑這個經驗