軟件測試開發(fā)工程師【SET】的生命

　　軟件測試開發(fā)工程師【Software Engineers in Test】是軟件工程師，專注在測試實現(xiàn)。首先，軟件測試開發(fā)工程師是開發(fā)角色，在招聘和內部晉升資料中被我們奉為的編碼角色。當在招聘面試軟件測試開發(fā)工程師的時候，對于編碼的要求幾乎和對軟件開發(fā)工程師的要求是一模一樣的，而且更強調如何去測試自己寫的代碼。換句話說，軟件開發(fā)工程師和軟件測試開發(fā)工程師都需要回答編碼問題，而且軟件測試開發(fā)工程師會被問到一系列測試相關的問題。

　　正如你可能想到的，這是一個很難滿足的角色。軟件測試開發(fā)工程師的數(shù)量如此之少的有可能的原因是，事實具備軟件測試開發(fā)工程師所需技能的人非常難找，而不是我們刻意使用了什么神奇的生產(chǎn)率公式【譯注，開發(fā)測試比率公式】， 這也是我們適應當前工程實踐的一個必然結果。我們還在優(yōu)化我們的工程實踐?這是一個非常重要的任務，并且為所有參與的人構建一些流程。

　　通常來說，軟件測試開發(fā)工程師不會在早期設計階段介入。不是故意這樣做，而是和多數(shù)谷歌的產(chǎn)品是如何誕生的有關。一個常見的新產(chǎn)品誕生的場景是這樣，已有的谷歌產(chǎn)品的員工會投入20%時間來開始新的產(chǎn)品。Gmail和Chrome OS這2個產(chǎn)品，從一個簡單的想法開始，并非正式地由谷歌授權去做的，慢慢地隨著時間的推移，越來越多的開發(fā)和測試加入進來并把產(chǎn)品發(fā)布。在這種情況下，早期的開發(fā)要關注的重心并不是質量，更關注提供一些理念，在解決了擴展性和性能的問題之后，再更多地關注質量。如果你創(chuàng)建了一個web service，但是不具有可擴展性時，測試這時候還并不是你大的問題。

　　一旦這個產(chǎn)品已經(jīng)明確未來可以發(fā)布的時候，研發(fā)團隊開始尋求測試的介入了。

　　你可以想象這樣一個過程，某個人有了一個好主意，他開始思考并寫了一些試驗性質的代碼，從其他人那里獲取一些建議然后對這些代碼做了改進，并勸說更多的人加入，寫了越來越多的代碼，然后意識到他們做的事情很重要，通過更多的代碼把這個想法變成可以呈現(xiàn)給他人并得到反饋的模型…  這個項目在谷歌的項目庫中創(chuàng)建了，這個項目慢慢地變成了一個真實的項目，測試也只有在項目變成真實的項目之后才會介入進來。

　　所有真實的項目都有專職的測試人員么？ 默認情況下是沒有的。小型項目和只有受限用戶使用的項目一般是開發(fā)人員自己做測試。其他的一些對個人或者企業(yè)用戶有潛在風險的項目，測試會介入。

　　當開發(fā)團隊尋求測試團隊參與并幫助他們時，他們有責任使測試人員相信他們的項目是令人興奮并充滿潛力的。開發(fā)總監(jiān)會給測試總監(jiān)解釋他們的項目、進度、發(fā)布計劃，一起討論測試工作如何劃分，并開發(fā)需要滿足的單元測試水平及開發(fā)參與測試工作程度上達成一致，發(fā)布流程中開發(fā)與測試的責任也需要明確。軟件測試開發(fā)工程師在項目初期可能不會參與進來，一旦項目變成真實的項目后，測試人員將在軟件開發(fā)過程中發(fā)揮巨大的影響力。

　　當我說“測試”時，并不是僅僅意味著單純的檢查驗證代碼路徑。測試人員不是從開始參與進來的，但“測試”卻至始至終都有。實際上，一個開發(fā)嘗試去check in代碼的時，測試人員的影響力在這個時刻可能已經(jīng)顯現(xiàn)出來了！咀g，這里指軟件測試開發(fā)工程師會對開發(fā)人員的測試程度做一些要求，開發(fā)人員在check in code的時候需要想一下自己是否滿足這些要求，這是測試人員的影響力】。歡迎繼續(xù)收聽并嘗試理解我所說的這些東西。