軟件測(cè)試開(kāi)發(fā)工程師(SET)的生命
軟件測(cè)試開(kāi)發(fā)工程師【Software Engineers in Test】是軟件工程師，專注在測(cè)試實(shí)現(xiàn)。首先，軟件測(cè)試開(kāi)發(fā)工程師是開(kāi)發(fā)角色，在招聘和內(nèi)部晉升資料中被我們奉為100%的編碼角色。當(dāng)在招聘面試軟件測(cè)試開(kāi)發(fā)工程師的時(shí)候，對(duì)于編碼的要求幾乎和對(duì)軟件開(kāi)發(fā)工程師的要求是一模一樣的，而且更強(qiáng)調(diào)如何去測(cè)試自己寫的代碼。換句話說(shuō)，軟件開(kāi)發(fā)工程師和軟件測(cè)試開(kāi)發(fā)工程師都需要回答編碼問(wèn)題，而且軟件測(cè)試開(kāi)發(fā)工程師會(huì)被問(wèn)到一系列測(cè)試相關(guān)的問(wèn)題。
正如你可能想到的，這是一個(gè)很難滿足的角色。軟件測(cè)試開(kāi)發(fā)工程師的數(shù)量如此之少的最有可能的原因是，事實(shí)具備軟件測(cè)試開(kāi)發(fā)工程師所需技能的人非常難找，而不是我們刻意使用了什么神奇的生產(chǎn)率公式【譯注，開(kāi)發(fā)測(cè)試比率公式】， 這也是我們適應(yīng)當(dāng)前工程實(shí)踐的一個(gè)必然結(jié)果。我們還在優(yōu)化我們的工程實(shí)踐–這是一個(gè)非常重要的任務(wù)，并且為所有參與的人構(gòu)建一些流程。
通常來(lái)說(shuō)，軟件測(cè)試開(kāi)發(fā)工程師不會(huì)在早期設(shè)計(jì)階段就介入。不是故意這樣做，而是和多數(shù)谷歌的產(chǎn)品是如何誕生的有關(guān)。一個(gè)常見(jiàn)的新產(chǎn)品誕生的場(chǎng)景是這樣，已有的谷歌產(chǎn)品的員工會(huì)投入20%時(shí)間來(lái)開(kāi)始新的產(chǎn)品。Gmail和Chrome OS這2個(gè)產(chǎn)品，從一個(gè)簡(jiǎn)單的想法開(kāi)始，并非正式地由谷歌授權(quán)去做的，慢慢地隨著時(shí)間的推移，越來(lái)越多的開(kāi)發(fā)和測(cè)試加入進(jìn)來(lái)并把產(chǎn)品發(fā)布。在這種情況下，早期的開(kāi)發(fā)要關(guān)注的重心并不是質(zhì)量，更關(guān)注提供一些理念，在解決了擴(kuò)展性和性能的問(wèn)題之后，再更多地關(guān)注質(zhì)量。如果你創(chuàng)建了一個(gè)web service，但是不具有可擴(kuò)展性時(shí)，測(cè)試這時(shí)候還并不是你最大的問(wèn)題。
一旦這個(gè)產(chǎn)品已經(jīng)明確未來(lái)可以發(fā)布的時(shí)候，研發(fā)團(tuán)隊(duì)就開(kāi)始尋求測(cè)試的介入了。
你可以想象這樣一個(gè)過(guò)程，某個(gè)人有了一個(gè)好主意，他開(kāi)始思考并寫了一些試驗(yàn)性質(zhì)的代碼，從其他人那里獲取一些建議然后對(duì)這些代碼做了改進(jìn)，并勸說(shuō)更多的人加入，寫了越來(lái)越多的代碼，然后意識(shí)到他們做的事情很重要，通過(guò)更多的代碼把這個(gè)想法變成可以呈現(xiàn)給他人并得到反饋的模型… 這個(gè)項(xiàng)目在谷歌的項(xiàng)目庫(kù)中就創(chuàng)建了，這個(gè)項(xiàng)目慢慢地變成了一個(gè)真實(shí)的項(xiàng)目，測(cè)試也只有在項(xiàng)目變成真實(shí)的項(xiàng)目之后才會(huì)介入進(jìn)來(lái)。
所有真實(shí)的項(xiàng)目都有專職的測(cè)試人員么？ 默認(rèn)情況下是沒(méi)有的。小型項(xiàng)目和只有受限用戶使用的項(xiàng)目一般是開(kāi)發(fā)人員自己做測(cè)試。其他的一些對(duì)個(gè)人或者企業(yè)用戶有潛在風(fēng)險(xiǎn)的項(xiàng)目，測(cè)試會(huì)介入。
當(dāng)開(kāi)發(fā)團(tuán)隊(duì)尋求測(cè)試團(tuán)隊(duì)參與并幫助他們時(shí)，他們有責(zé)任使測(cè)試人員相信他們的項(xiàng)目是令人興奮并充滿潛力的。開(kāi)發(fā)總監(jiān)會(huì)給測(cè)試總監(jiān)解釋他們的項(xiàng)目、進(jìn)度、發(fā)布計(jì)劃，一起討論測(cè)試工作如何劃分，并就開(kāi)發(fā)需要滿足的單元測(cè)試水平及開(kāi)發(fā)參與測(cè)試工作程度上達(dá)成一致，發(fā)布流程中開(kāi)發(fā)與測(cè)試的責(zé)任也需要明確。軟件測(cè)試開(kāi)發(fā)工程師在項(xiàng)目初期可能不會(huì)參與進(jìn)來(lái)，一旦項(xiàng)目變成真實(shí)的項(xiàng)目后，測(cè)試人員將在軟件開(kāi)發(fā)過(guò)程中發(fā)揮巨大的影響力。
當(dāng)我說(shuō)“測(cè)試”時(shí)，并不是僅僅意味著單純的檢查驗(yàn)證代碼路徑。測(cè)試人員不是從開(kāi)始就參與進(jìn)來(lái)的，但“測(cè)試”卻至始至終都有。實(shí)際上，一個(gè)開(kāi)發(fā)嘗試去check in代碼的時(shí)，測(cè)試人員的影響力在這個(gè)時(shí)刻可能就已經(jīng)顯現(xiàn)出來(lái)了?！咀g，這里指軟件測(cè)試開(kāi)發(fā)工程師會(huì)對(duì)開(kāi)發(fā)人員的測(cè)試程度做一些要求，開(kāi)發(fā)人員在check in code的時(shí)候需要想一下自己是否滿足這些要求，這就是測(cè)試人員的影響力】。歡迎繼續(xù)收聽(tīng)并嘗試?yán)斫馕宜f(shuō)的這些東西。
公直
2012/6/28
#p#
英文原文，
How Google Tests Software – Part Six
http://googletesting.blogspot.com/2011/05/how-google-tests-software-part-six.html
Monday, May 02, 2011 12:05 PM
By James Whittaker
The Life of an SET
SETs are Software Engineers in Test. They are software engineers who happen to write testing functionality. First and foremost, SETs are developers and the role is touted as a 100% coding role in our recruiting literature and internal job promotion ladders. When SET candidates are interviewed, the “coding bar” is nearly identical to the SWE role with more emphasis that SETs know how to test the code they create. In other words, both SWEs and SETs answer coding questions. SETs are expected to nail a set of testing questions as well.
As you might imagine, it is a difficult role to fill and it is entirely possible that the low numbers of SETs isn’t because Google has created a magic formula for productivity but more of a result of adapting our engineering practice around the reality that the SET skill set is really hard to find. We optimize on this very important task and build processes around the people who do it.
It is usually the case that SETs are not involved early in the design phase. Their exclusion is not so much purposeful as it is a by-product of how a lot of Google projects are born. A common scenario for new project creation is that some informal 20% effort takes a life of its own as an actual Google branded product. Gmail and Chrome OS are both projects that started out as ideas that were not formally mandated by Google but over time grew into shipping products with teams of developers and testers working on them. In such cases early development is not about quality, it is about proving out a concept and working on things like scale and performance that must be right before quality could even be an issue. If you can’t build a web service that scales, testing is not your biggest problem!
Once it is clear that a product can and will be built and shipped, that’s when the development team seeks out test involvement.
You can imagine a process like this: someone has an idea, they think about it, write experimental code, seek out opinions of others, write some more code, get others involved, write even more code, realize they are onto something important, write more code to mold the idea into something that they can present to others to get feedback … somewhere in all this an actual project is created in Google’s project database and the project becomes real. Testers don’t get involved until it becomes real.
Do all real projects get testers? Not by default. Smaller projects and those meant for limited users often get tested exclusively by the people who build it. Others that are riskier to our users or the enterprise (much more about risk later) get testing attention.
The onus is on the development teams to solicit help from testers and convince them that their project is exciting and full of potential. Dev Directors explain their project, progress and ship schedule to Test Directors who then discuss how the testing burden is to be shared and agree on things like SWE involvement in testing, expected unit testing levels and how the duties of the release process are going to be shared. SETs may not be involved at project inception, but once the project becomes real we have vast influence over how it is to be executed.
And when I say “testing” I don’t just mean exercising code paths. Testers might not be involved from the beginning … but testing is. In fact, an SET’s impact is felt even before a developer manages to check code into the build. Stay tuned to understand what I am talking about.
