來源：黃利
軟體測試開發工程師（SET）的生命
軟體測試開發工程師（Software Engineers in Test）是軟體工程師，專注在測試實現。首先，軟體測試開發工程師是開發角色，在招聘和內部晉升資料中被我們奉為100%的編碼角色。當在招聘面試軟體測試開發工程師的時候，對於編碼的要求幾乎和對軟體開發工程師的要求是一模一樣的，而且更強調如何去測試自己寫的程式碼。換句話說，軟體開發工程師和軟體測試開發工程師都需要回答編碼問題，而且軟體測試開發工程師會被問到一系列測試相關的問題。
正如你可能想到的，這是一個很難滿足的角色。軟體測試開發工程師的數量如此之少的最有可能的原因是，事實具備軟體測試開發工程師所需技能的人非常難找，而不是我們刻意使用了什麼神奇的生產率公式（譯註，開發測試比率公式）， 這也是我們適應當前工程實踐的一個必然結果。我們還在優化我們的工程實踐–這是一個非常重要的任務，並且為所有參與的人構建一些流程。
通常來說，軟體測試開發工程師不會在早期設計階段就介入。不是故意這樣做，而是和多數谷歌的產品是如何誕生的有關。一個常見的新產品誕生的常ò是這樣，已有的谷歌產品的員工會投入20%時間來開始新的產品。Gmail和Chrome OS這2個產品，從一個簡單的想法開始，並非正式地由谷歌授權去做的，慢慢地隨著時間的推移，越來越多的開發和測試加入進來並把產品釋出。在這種情況下，早期的開發要關注的重心並不是質量，更關注提供一些理念，在解決了擴充套件性和效能的問題之後，再更多地關注質量。如果你建立了一個web service，但是不具有可擴充套件性時，測試這時候還並不是你最大的問題。
一旦這個產品已經明確未來可以釋出的時候，研發團隊就開始尋求測試的介入了。
你可以想象這樣一個過程，某個人有了一個好主意，他開始思考並寫了一些試驗性質的程式碼，從其他人那裡獲取一些建議然後對這些程式碼做了改進，並勸說更多的人加入，寫了越來越多的程式碼，然後意識到他們做的事情很重要，通過更多的程式碼把這個想法變成可以呈現給他人並得到反饋的模型… ?這個專案在谷歌的專案庫中就建立了，這個專案慢慢地變成了一個真實的專案，測試也只有在專案變成真實的專案之後才會介入進來。
所有真實的專案都有專職的測試人員麼？ 預設情況下是沒有的。小型專案和只有受限使用者使用的專案一般是開發人員自己做測試。其他的一些對個人或者企業使用者有潛在風險的專案，測試會介入。
當開發團隊尋求測試團隊參與並幫助他們時，他們有責任使測試人員相信他們的專案是令人興奮並充滿潛力的。開發總監會給測試總監解釋他們的專案、進度、釋出計劃，一起討論測試工作如何劃分，並就開發需要滿足的單元測試水平及開發參與測試工作程度上達成一致，釋出流程中開發與測試的責任也需要明確。軟體測試開發工程師在專案初期可能不會參與進來，一旦專案變成真實的專案後，測試人員將在軟體開發過程中發揮巨大的影響力。
當我說“測試”時，並不是僅僅意味著單純的檢查驗證程式碼路徑。測試人員不是從開始就參與進來的，但“測試”卻至始至終都有。實際上，一個開發嘗試去check in程式碼的時，測試人員的影響力在這個時刻可能就已經顯現出來了。（譯，這裡指軟體測試開發工程師會對開發人員的測試程度做一些要求，開發人員在check in code的時候需要想一下自己是否滿足這些要求，這就是測試人員的影響力）。歡迎繼續收聽並嘗試理解我所說的這些東西。