跟谷歌測試工程師的對話

　　Alan Faulkner是谷歌的測試工程師，他的工作物件是谷歌的DoubleClick廣告報價管理系統(Bid Manager)，這個系統提供讓廣告代理商和廣告客戶在多個廣告上進行報價競標的功能。Bid Manager是谷歌2010年收購的Invite Media系統的下一代產品。 Alan Faulkner的主要工作負責Bid Manager系統用來移植資料的元件，這些元件用來把Invite Media中的廣告客戶資訊轉換到Bid Manager系統中。Alan Faulkner 2011年進入谷歌，工作地點是位於華盛頓的柯克蘭辦公室。

本文的主人公alan

你是測試工程師，還是編寫測試程式碼的軟體工程師？這兩者之間有什麼區別？

　　目前我是測試工程師，但這兩種角色非常的相似。作為測試工程師，你更多的是專注於產品的總體質量和軟體釋出的速度，而編寫測試程式碼的軟體工程師更多的是關注測試框架，自動化測試和為測試重構程式碼。我想這兩者之間的不同更多的是關注點，而不是能力問題，因為在谷歌，這兩種角色都需要能寫出產品級質量的程式碼。例如，我所做的測試工程師的任務是引入自動化的釋出過程，為團隊劃分模組來提高測試覆蓋率，減少校驗資料正確性時需要的手工操作步驟。

你的典型的一天的工作是個什麼樣的情形？

　　當來到公司，我首先去看哪些程式碼審查是需要回復的，看看哪些從技術客戶經理髮過來的bug是具有高優先順序的，然後開始寫程式碼。在當前的職務上，我的主要精力是放在提高大規模整合測試和測試框架上的測試有效性和覆蓋率。我也會在我們的產品中增加一些功能特徵，來改進測試有效性。我的時間的50%到75%會花在寫程式碼上或程式碼審查上。

你只寫測試程式碼嗎？

　　不是的，我寫的很多程式碼會留在釋出的產品中。在谷歌做SET或TE的一個最大的好處是：你寫產品程式碼就像寫測試程式碼一樣簡單。我兩者都寫。我寫的測試程式碼主要是用來改進測試框架，讓開發人員能寫出整合性好的測試程式。我寫的產品程式碼主要是來改進對外部輸入資料的驗證。我還會寫一些來提高可測試性的功能程式碼。這些程式碼能給產品帶來質量更高的功能特徵，避免了讓產品依賴於測試程式來發現其中的問題。

你用什麼語言開發？

　　測試程式碼和產品程式碼大部分都是使用Java。偶爾也會使用Python或C++。

手工測試會佔用你多少時間？

　　目前，在這個崗位上，我手工測試的時間少於5%。經過某些探索式的測試能幫助提高對產品的認識、發現某些風險的存在，但這些不會反覆的出現，也不多。需要手工的步驟很少，我的任務就行幫助減少這種操作，所以團隊不會讓我去做那些資料遷移中反覆的手工測試工作。

你不是給自己的程式碼寫測試程式碼吧？

　　在谷歌，測試的任務是在所有工程師間交叉分攤的，並不是只由測試工程師來做。每個人都要為他們的元件寫出單元測試程式碼，就像整合測試工作一樣。這就是說，我寫的測試用例針對的元件並不是我開發的，但這些元件需要有說明如何為它寫測試程式碼。這些元件通常牽涉到非常複雜的程式碼或需要用新的模擬框架，例如Mockito。

開發谷歌的廣告產品，哪些是你喜歡的？

　　我喜歡我們需要解決的問題中的海量或高效能所帶來的挑戰——從處理海量資料到在毫秒級間實時對大量的廣告請求進行響應。我還喜歡我們產品的影響力，因為這些產品會牽涉到很多的使用者。這是工作在這樣的產品上獲得的回報。

　　依你的經驗，谷歌的測試工作和你乾的其它公司裡有什麼不同？

　　我感覺在谷歌，這個角色非常的靈活。在我的團隊裡很少區分這是SET的那是TE的，每個人可以靈活的選擇他們認為最重要的工作去做。例如，我寫了很多的產品程式碼，修改了很多產品中的bug，提高程式碼的可測試性，增加在遷移資料中對錯誤資料的可觀察性。同時，谷歌的很多開發人員卻在花大量的時間測試程式碼，所以說，測試不是我的唯一任務。

在谷歌柯克蘭工作區工作和在谷歌總部工作有什麼不同？

　　我真正喜歡谷歌的地方是它的各個辦公區各有自己本地風格和個性。谷歌提倡這樣。例如，位於柯克蘭的辦公區有攀巖和划船設施，我們辦公大樓裡的所有會議室都是以本地品牌命名的。位於西雅圖的辦公室有皮划艇，而紐約的辦公區裡在自主餐廳裡有食品車。

谷歌的這種測試文化有前途嗎？

　　我覺得前途一片光明。我們有很大的靈活性，能對產品的質量和可測試性產生重大積極的影響，能提高產品釋出的速度。我們需要快速的產品釋出和高質量的產品釋出。問題是我們面對的問題很複雜，而且要求很苛刻。我們需要用技術來確保團隊有有效的測試方式。這是所有在谷歌的測試人員和工作中這個領域的開發人員的努力目標。

英文原文：Conversation with a Test Engineer