在Google,品質並不等於測試。我相信在任何一個地方都是如此。“品質不是被測試出來的”這句老話是再正確不過了。從汽車到軟體,如果它們起初製造的就有問題,那它們永遠都不會沒問題。試問任何一個曾經被迫大量召回的汽車公司,掩蓋品質問題的代價有多大。
然而,事實情況並不是像這句話那樣既簡單又精確。雖然品質並不是測試出來的,但我們有同樣的證據表明,沒有測試,你不可能開發出任何有品質的東西。一個人怎麼可能在沒有測試的情況下認定你的工程具有高品質?
對於這種難題,最簡單的解決辦法就是:禁止對開發工作開方便之門,以獨立自由之精神進行測試。測試和開發工作需要同步進行。編寫一點,測試一點。再編寫一點,再測試一點。更好的方法是制定測試計劃,或者你開發之前先把計劃做好。測試並不是一個獨立的工作,它是開發工作的一部分,伴隨著整個開發過程。品質不等於測試;為了品質,需要你把開發工作和測試結合到一起,攪拌它們,直到分不清你我為止。
在Google,這是我們明確的目標:把開發與測試融合,你不能單獨進行任何一項工作。做一點,測試一點。再做一點,再測試一點。關鍵就是看誰在做測試。因為在Google,專職測試人員是出奇的少,所以唯一可行的方法就是使用開發人員。還有比這些實際開發了這些程式的人員更合適做測試的嗎?還有比程式的作者更適合去發現bug的嗎?是誰具有更多的願望在程式第一次寫出時避免bug?Google之所以安排這麼少的專職測試人員的原因就是,開發人員負責品質。事實上,堅持使用大型測試機構的團隊通常會開發出有問題的東西。測試機構龐大,這是一個訊號表明編碼/測試工作的融和有問題。增加測試人員並不能解決任何問題。
這就是說,品質措施更多的應該是一種預防行為,而不是一種發現過程。品質屬於開發問題,而不是測試問題。通過把測試工作一定程度的融合到開發過程中,我們極大的降低了一些本來被認為會寫很多有問題的代碼的人的出錯機會。我們不僅避免了大量的客戶方的問題,我們還非常有效降低了測試人員提出的、其實不是bug的bug。在Google,測試工作的目標就是檢查這些預防工作是否在有效運行。測試工程部一直在尋找這種作為bug創造者的軟體工程師和作為bug預防者的測試軟體工程師之間的聯合能達到的效果的證據,一旦這個方法出現問題,他們就會拉響警笛。
這種開發與測試的結合隨處可見,從代碼審查注釋上寫的“你的測試呢?”到廁所裡的給開發人員的最好的測試實踐方法的宣傳畫——這是我們臭名昭著的廁所測試指導方針。測試是開發工作中是必不可少的,開發與測試的聯姻是孕育品質的過程。軟工就是測試者,測試軟工就是測試者,測試工程師就是測試者。
如果你的企業也有這種類型的結合,請分享出你們成功的經驗與挑戰。如果沒有,那麼這是一個給你的企業帶來好處的機會:在開發人員和品質之間畫上全等號。
from:http://tech.it168.com/a2011/0322/1168/000001168717.shtml