在前兩部分的文章中，很多人在評論里提出了問題。我沒有忘記他們。希望大部分的人能在余下的幾部分文章里找到答案。我現在還是開始這篇文章的主題。

　　在Google，質量并不等于測試。我相信在任何一個地方都是如此。質量不是被測試出來的這句老話是再正確不過了。從汽車到軟件，如果它們起初制造的就有問題，那它們永遠都不會沒問題。試問任何一個曾經被迫大量召回的汽車公司，掩蓋質量問題的代價有多大。

　　然而，事實情況并不是像這句話那樣既簡單又精確。雖然質量并不是測試出來的，但我們有同樣的證據表明，沒有測試，你不可能開發出任何有質量的東西。一個人怎么可能在沒有測試的情況下認定你的工程具有高質量？

　　對于這種難題，最簡單的解決辦法就是：禁止對開發工作開方便之門，以獨立自由之精神進行測試。測試和開發工作需要同步進行。編寫一點，測試一點。再編寫一點，再測試一點。更好的方法是制定測試計劃，或者你開發之前先把計劃做好。測試并不是一個獨立的工作，它是開發工作的一部分，伴隨著整個開發過程。質量不等于測試；為了質量，需要你把開發工作和測試結合到一起，攪拌它們，直到分不清你我為止。

　　在Google，這是我們明確的目標：把開發和測試融合，你不能單獨進行任何一項工作。做一點，測試一點。再做一點，再測試一點。關鍵就是看誰在做測試。因為在Google，專職測試人員是出奇的少，所以唯一可行的方法就是使用開發人員。

　　還有比這些實際開發了這些程序的人員更合適做測試的嗎？還有比程序的作者更適合去發現bug的嗎？是誰具有更多的愿望在程序第一次寫出時避免bug？Google之所以安排這么少的專職測試人員的原因就是，開發者負責質量。事實上，堅持使用大型測試機構的團隊通常會開發出有問題的東西。測試機構龐大，這是一個信號表明編碼/測試工作的融和有問題。增加測試人員并不能解決任何問題。

　　這就是說，質量措施更多的應該是一種預防行為，而不是一種發現過程。質量屬于開發問題，而不是測試問題。通過把測試工作一定程度的融合到開發過程中，我們極大的降低了一些本來被認為會寫很多有問題的代碼的人的出錯機會。我們不僅避免了大量的客戶方的問題，我們還非常有效的降低了測試人員提出的、其實不是bug的bug。在Google，測試工作的目標就是檢查這些預防工作是否在有效的運行。測試工程部一直在尋找這種作為bug創造者的軟件工程師和作為bug預防者的測試軟件工程師之間的聯合能達到的效果的證據，一旦這個方法出現問題，他們就會拉響警笛。

　　這種開發和測試的結合隨處可見，從代碼審查注釋上寫的你的測試呢？到廁所里的給開發者的最好的測試實踐方法的宣傳畫——這是我們臭名昭著的廁所測試指導方針。測試是開發工作中是必不可少的，開發和測試的聯姻是孕育質量的過程。軟工就是測試者，測試軟工就是測試者，測試工程師就是測試者。

　　如果你的企業也有這種類型的結合，請分享出你們成功的經驗與挑戰。如果沒有，那么這是一個給你的企業帶來好處的機會：在開發人員和質量之間畫上全等號。你們都聽過這樣一個老故事：小雞很高興能為一頓咸豬腿加雞蛋早餐奉獻自己的力量，可豬究竟做錯了什么？的確是 … 去對你的開發人員哼哼兩聲，看能不能得到他們哼哼回應。如果他們發出的是咯咯噠的聲音，那說明你們之間存在問題。