|
（一）
google在公司的大層面組織上有很多的Focus Area，search, apps, ads, mobile, operating
system這些都是不同的FA。測(cè)試隸屬于其中的一個(gè)FA，這個(gè)FA的名字叫Engineering Productivity。這個(gè)FA由很多縱向的橫向的學(xué)科構(gòu)成，測(cè)試是其中最大的一個(gè)學(xué)科。Eng Prod這個(gè)FA由下面的部分組成：
從上面的表述可以看出來(lái)，測(cè)試工程師在google其實(shí)就是Eng Prod這個(gè)部門(mén)下面的Embedded engineers，他們要向Eng Prod的匯報(bào)，但是卻工作生活在別的產(chǎn)品團(tuán)隊(duì)，比如Search、gmail等?？墒撬麄儾幌虍a(chǎn)品團(tuán)隊(duì)的人匯報(bào)，這種“分開(kāi)匯報(bào)”方式的好處是他提供了一個(gè)forum，可以讓測(cè)試工程師分享他們的知識(shí)。在 Eng Prod 中Good testing ideas可以很容易產(chǎn)生。 把項(xiàng)目線和匯報(bào)線分開(kāi)有它的挑戰(zhàn)。目前最大的挑戰(zhàn)是：測(cè)試是（產(chǎn)品團(tuán)隊(duì)的）外部資源。產(chǎn)品團(tuán)隊(duì)不能指望測(cè)試工程師保證質(zhì)量，而是要自己來(lái)確保。在Google產(chǎn)品質(zhì)量是產(chǎn)品團(tuán)隊(duì)自己的事情，不是測(cè)試工程師的事情。每個(gè)開(kāi)發(fā)工程師要自己來(lái)做測(cè)試。測(cè)試工程師的任務(wù)是確保他們有測(cè)試的自動(dòng)化框架，另外還要建立一種有利于“自依賴(lài)”（開(kāi)發(fā)依賴(lài)自己的測(cè)試來(lái)保證質(zhì)量）的流程?？偨Y(jié)起來(lái)就是：測(cè)試工程師讓開(kāi)發(fā)工程師更舒服的來(lái)測(cè)試自己的代碼。 我（James）之所以喜歡這種方式，在于他把開(kāi)發(fā)和測(cè)試人員放到了相同的位置（不存在上下游關(guān)系）。他讓測(cè)試開(kāi)發(fā)成為伙伴，并且把最大的質(zhì)量任務(wù)給了開(kāi)發(fā)，致力于讓產(chǎn)品正確運(yùn)行的開(kāi)發(fā)自己。另外一個(gè)副效應(yīng)就是做到一個(gè)很高的開(kāi)發(fā)測(cè)試比。產(chǎn)品團(tuán)隊(duì)?wèi)?yīng)當(dāng)以此為榮！ 上面這種策略的弊病在于開(kāi)發(fā)通常自己不能確保自己的質(zhì)量，在Google我們解決這個(gè)問(wèn)題的方法是建立兩種類(lèi)型的測(cè)試角色，來(lái)解決兩種完全不同的測(cè)試問(wèn)題，這個(gè)劃分是： （二）
（下面的這幾段分析比較深入）
從質(zhì)量的角度來(lái)看，SWE要分別對(duì)產(chǎn)品的功能和他的質(zhì)量負(fù)責(zé)。他們要做到容錯(cuò)的設(shè)計(jì)、故障恢復(fù)、測(cè)試驅(qū)動(dòng)開(kāi)發(fā)、單元測(cè)試，并且還要和在SET的協(xié)助下編寫(xiě)代碼測(cè)試他們的功能。（feature就是用戶(hù)可以用到的功能，而這里作者列舉的容錯(cuò)等都算是產(chǎn)品的質(zhì)量維度。）
SET也是開(kāi)發(fā)者，他們提供的產(chǎn)品功能（feature）是供測(cè)試使用的。例如：一個(gè)通過(guò)使用“待實(shí)現(xiàn)代碼”（原文是stubs，我理解是code stub）模擬依賴(lài)的框架，從而能把新開(kāi)發(fā)的代碼分離出系統(tǒng)來(lái)測(cè)試（其實(shí)就是mock框架，gmock的功能）。簡(jiǎn)言之，SET編寫(xiě)的代碼是為了能讓SWE更方便的測(cè)試自己的功能。真正的測(cè)試工作是由SWE來(lái)做的。SET只確保SWE完成的功能是可測(cè)試的，SWE自己來(lái)完成寫(xiě)test
case的工作。SET的關(guān)注的是SWE。具體功能的質(zhì)量是最終目標(biāo)，怎么讓SWE能夠容易的測(cè)試自己的代碼是SET首要側(cè)重點(diǎn)。這里有一個(gè)明顯的質(zhì)量漏洞，功能的使用者——終端用戶(hù)呢？
在Google用戶(hù)體驗(yàn)的測(cè)試是TE的事情。假設(shè)SWE和SET做的模塊、功能測(cè)試都足夠充分了，后面的任務(wù)就是這些程序和數(shù)據(jù)能不能有效的來(lái)滿(mǎn)足用戶(hù)的需求了。TE在這里是一個(gè)double-check。任何明顯的bug說(shuō)明SWE的測(cè)試不充分馬虎。當(dāng)這種bug難覓的時(shí)候，TE就可以轉(zhuǎn)向他們最重要的任務(wù)了，這些任務(wù)有：確保軟件完成了用戶(hù)場(chǎng)景，性能上、安全上、國(guó)際化上都OK。TE要做很多的測(cè)試和測(cè)試協(xié)調(diào)工作，這種協(xié)調(diào)工作牽扯的角色很多，有：TE,
contract testers, crowd sourced testers, dog fooders, beta users, early adopters（這里不直譯了，contract表示契約，可以當(dāng)做需求來(lái)理解；sourced指的是外包，可見(jiàn)google也有外包的產(chǎn)品；dog fooders是說(shuō)公司的產(chǎn)品都要在公司內(nèi)部先開(kāi)展試用，公司鼓勵(lì)每個(gè)人都試用自己的產(chǎn)品，這就叫eating your own dog food，dog fooder值得就是使用過(guò)自己產(chǎn)品的員工；beta用戶(hù)是公測(cè)用戶(hù)；early
adopter就是嘗鮮者，可以理解為發(fā)布后首先使用的人員。總之就是從產(chǎn)品）。他們要跟各種團(tuán)體溝通的事情很多，包括：設(shè)計(jì)上固有的風(fēng)險(xiǎn)、功能的復(fù)雜性、避免故障的方法。一旦當(dāng)TE介入，他們的工作沒(méi)有盡頭。（感覺(jué)TE更像是涵蓋了產(chǎn)品的運(yùn)營(yíng)任務(wù)，不是運(yùn)維哦）。
（三） 首先明確，質(zhì)量是測(cè)試不出來(lái)的。有個(gè)比喻很有意思：不能通過(guò)反復(fù)測(cè)試來(lái)提高質(zhì)量，這就好像你不能通過(guò)反復(fù)稱(chēng)重來(lái)減肥一樣。
在Google，質(zhì)量不等于測(cè)試，有些公司則不然。“質(zhì)量不能通過(guò)測(cè)試而植入”這個(gè)是老生常談了，我們不必去懷疑他的正確性。從手機(jī)到軟件，如果你沒(méi)有在一開(kāi)始就把它構(gòu)建好，那么他永遠(yuǎn)不會(huì)正確的工作。如果你不知道一開(kāi)始不重視質(zhì)量的代價(jià)，那么去問(wèn)問(wèn)陷入“召回門(mén)”的汽車(chē)廠吧。
“質(zhì)量不能通過(guò)測(cè)試而植入”這話本身并不通俗，它也不是一個(gè)準(zhǔn)確的描述?？墒菫槭裁催@么說(shuō)？因?yàn)轱@然，如果沒(méi)有測(cè)試你不可能開(kāi)發(fā)出什么高質(zhì)量的東西。對(duì)啊，如果你不測(cè)試，你怎么知道你開(kāi)發(fā)出來(lái)的東西就是高質(zhì)量的呢？
解決這個(gè)問(wèn)題的簡(jiǎn)單方法就是不要把開(kāi)發(fā)和測(cè)試當(dāng)做兩個(gè)單獨(dú)的學(xué)科。測(cè)試和開(kāi)發(fā)應(yīng)該是起頭并進(jìn)的——寫(xiě)一點(diǎn)、測(cè)一點(diǎn)；寫(xiě)一坨，測(cè)一坨。更好的方法是，在你寫(xiě)代碼的時(shí)候就準(zhǔn)備如何測(cè)試，甚至是在寫(xiě)代碼之前。測(cè)試并不是一類(lèi)單獨(dú)實(shí)踐藝術(shù)，他是開(kāi)發(fā)過(guò)程的一個(gè)部分。質(zhì)量不等于測(cè)試，好的質(zhì)量是通過(guò)把開(kāi)發(fā)和測(cè)試有機(jī)粘合在一起來(lái)實(shí)現(xiàn)的，以致你不能區(qū)分出對(duì)方。
上面的描述就是我們?cè)贕oogle的目標(biāo)：合并開(kāi)發(fā)和測(cè)試直到你不能在沒(méi)有其中一個(gè)的時(shí)候完成另外一個(gè)。構(gòu)建一尺，測(cè)試一尺；構(gòu)建一丈，測(cè)試一丈。這里的關(guān)鍵問(wèn)題是：誰(shuí)來(lái)做這個(gè)測(cè)試。鑒于Google中全職的測(cè)試工程師從比例上來(lái)講少得可憐，那么答案自然是開(kāi)發(fā)工程師。有誰(shuí)比代碼的編寫(xiě)者自己來(lái)做測(cè)試更合適呢？有誰(shuí)比他自己來(lái)發(fā)現(xiàn)bug更合適呢？誰(shuí)會(huì)對(duì)能在第一時(shí)間避免bug更振奮呢？Google之所以能夠在測(cè)試工程師這么少的情況下還能這么得瑟，就是因?yàn)殚_(kāi)發(fā)對(duì)質(zhì)量負(fù)責(zé)。事實(shí)上，堅(jiān)持保留一個(gè)大量測(cè)試的團(tuán)隊(duì)通常被認(rèn)為是在犯錯(cuò)。保有一個(gè)大型測(cè)試團(tuán)隊(duì)是“開(kāi)發(fā)工作/測(cè)試工作”嚴(yán)重失衡的標(biāo)志，增加更多的專(zhuān)職測(cè)試人員是不會(huì)解決問(wèn)題的。
換句話說(shuō)：質(zhì)量保證是重預(yù)防而不是重檢測(cè)。質(zhì)量保證是一個(gè)開(kāi)發(fā)問(wèn)題，而不是一個(gè)測(cè)試問(wèn)題。通過(guò)“把測(cè)試簽入到開(kāi)發(fā)中”，我們建立了一個(gè)“超增量”的過(guò)程，能做到“當(dāng)一個(gè)改動(dòng)導(dǎo)致錯(cuò)誤太多，那么就會(huì)自動(dòng)回滾”。我們不單是避免了很多用戶(hù)問(wèn)題，而且大幅降低了用來(lái)確?！皼](méi)有recall-class
bug”的測(cè)試工程師的數(shù)量。在Google，測(cè)試的目的就是發(fā)現(xiàn)這種“避免問(wèn)題”的方式是不是做的足夠好。TE時(shí)刻會(huì)關(guān)注SWE-SET的這種組合是不是能達(dá)到“避免用戶(hù)問(wèn)題”的目的，一旦流程出現(xiàn)了問(wèn)題TE就會(huì)發(fā)出警告。
團(tuán)隊(duì)的各種跡象都能體現(xiàn)這種測(cè)試和開(kāi)發(fā)的融合，從code review中的“你的測(cè)試呢”到廁所中大幅海報(bào)提醒開(kāi)發(fā)者采納最佳的測(cè)試實(shí)踐——臭名昭著的“Testing On The Toilet”提示。測(cè)試必須成為開(kāi)發(fā)不可回避的一面，開(kāi)發(fā)和測(cè)試的聯(lián)姻的那天就是質(zhì)量能夠得到保證的那天。SWE是測(cè)試工程師，SET是測(cè)試工程師，TE也是測(cè)試工程師。
如果你的組織也在做這種融合，何不分享你的成功和挑戰(zhàn)呢？如果你們的組織不在嘗試這種融合，那么這是你們組織可以嘗試的一個(gè)變化：讓開(kāi)發(fā)工程師全權(quán)承擔(dān)起質(zhì)量的任務(wù)。有句諺語(yǔ)說(shuō)得好chickens are happy to contribute to a bacon and egg
breakfast but the pig is fully committed（意思是說(shuō)，雞愿意為“雞蛋咸肉”早餐貢獻(xiàn)一份力量，而豬不愿意。因?yàn)殡u只是提供了雞蛋，自己毫發(fā)無(wú)損，而豬卻把自己都押上了。其實(shí)就是說(shuō)要把開(kāi)發(fā)置于死地而后生，讓他們自己測(cè)）。這樣一來(lái)你如果發(fā)現(xiàn)你的開(kāi)發(fā)工程師發(fā)出豬的叫聲這就ok了，如果他們發(fā)出雞的叫聲那就有問(wèn)題了。
（四）
匍匐、步行、跑步向前
之所以Google的測(cè)試人員相比其他公司非常少但是卻還可以保持較好的質(zhì)量，一個(gè)首要的原因就是：我們很少試圖一次性發(fā)布很多功能。事實(shí)上，我們做的恰恰相反：首先構(gòu)建一個(gè)產(chǎn)品的核心部分，并在他能惠及盡量一個(gè)大群體客戶(hù)的時(shí)候就發(fā)布他，然后收集反饋意見(jiàn)并且迭代改進(jìn)。我們就是這么來(lái)開(kāi)發(fā)Gmail的，以至于beta標(biāo)簽在這個(gè)產(chǎn)品上呆了4年。這個(gè)標(biāo)簽也讓我們的用戶(hù)知道這是一個(gè)在不斷完善的產(chǎn)品。直到我們能夠保證用戶(hù)email數(shù)據(jù)達(dá)到99.99%的可用性的時(shí)候我們才把這個(gè)beta標(biāo)簽取消?？吹搅藳](méi)，質(zhì)量的改善貫穿整個(gè)工作當(dāng)中。
通過(guò)這個(gè)過(guò)程（確保質(zhì)量）并不是一個(gè)很冒險(xiǎn)的過(guò)程。事實(shí)上，為了能到達(dá)beta階段，一個(gè)產(chǎn)品必須經(jīng)過(guò)很多的其他階段并證明它的價(jià)值。比如Chrome（我才開(kāi)始來(lái)的時(shí)候在這個(gè)產(chǎn)品上做了2年），我們會(huì)依據(jù)我們?cè)诋a(chǎn)品上的信心和反饋的程度不同來(lái)確定我們要引入多少個(gè)階段。例如：
Canary Channel。這個(gè)階段適用于那些不適合發(fā)布的代碼。就好像是煤礦中的金絲雀，如果它不能活下來(lái)，我們還要努力。這個(gè)階段構(gòu)建的程序只能提供給那些具有超強(qiáng)耐受度的用戶(hù)，讓他們拿它來(lái)做實(shí)驗(yàn)，不指望它能完成真正的工作。
Dev Chanel。提供給開(kāi)發(fā)者在日常工作中來(lái)使用。我們鼓勵(lì)產(chǎn)品線上的每個(gè)工程師都把它拿來(lái)并應(yīng)用到真正的工作當(dāng)中。
Test Channel。這個(gè)階段構(gòu)建好的程序會(huì)提供給公司內(nèi)部所有的員工來(lái)使用，如果那性能也足夠好的話他也代表了一個(gè)準(zhǔn)Beta版。
The Beta Channel or Release
Channel。這個(gè)階段構(gòu)建出來(lái)的程序?qū)⒊蔀槭状螌?duì)外公開(kāi)的程序。一個(gè)產(chǎn)品只有在上面的各階段呆夠了足夠的時(shí)間后，他才能最終贏得一個(gè)在“槍林彈雨搬的測(cè)試和真實(shí)使用”下露面的機(jī)會(huì)。
這種“匍匐、步行、跑步向前”的方式讓我們能夠盡早的在我們的產(chǎn)品上測(cè)試、做實(shí)驗(yàn)，并從用戶(hù)真實(shí)使用和每個(gè)階段的自動(dòng)化測(cè)試中收集各種反饋信息。
（五）
在測(cè)試層級(jí)的劃分方面我們沒(méi)有采用代碼級(jí)、集成級(jí)、系統(tǒng)級(jí)這樣的分類(lèi)方式，取而代之的小測(cè)試、中測(cè)試、大測(cè)試，這樣做是為了強(qiáng)調(diào)測(cè)試的規(guī)模而不是外在形式。小測(cè)試只會(huì)覆蓋一小撮代碼，然后是中、大測(cè)試。不論是SWE、SET、還是TE，都會(huì)執(zhí)行這三類(lèi)的測(cè)試，可能是通過(guò)自動(dòng)化的方式開(kāi)展也可能是手工的方式。
小測(cè)試通常（但不總是）通過(guò)自動(dòng)化的方式來(lái)運(yùn)行，它只會(huì)運(yùn)行一個(gè)函數(shù)或一個(gè)模塊的代碼。通常他們都是由SWE或SET來(lái)完成編寫(xiě)的，他們的運(yùn)行可能會(huì)需要mock環(huán)境，TE通常會(huì)在需要診斷一個(gè)具體問(wèn)題的時(shí)候直接拿過(guò)來(lái)運(yùn)行。對(duì)于小測(cè)試來(lái)說(shuō)他們關(guān)注的是些典型的問(wèn)題，如數(shù)據(jù)損壞、錯(cuò)誤條件或一個(gè)錯(cuò)誤。一個(gè)小測(cè)試要回答的問(wèn)題是：代碼是不是完成了它應(yīng)有的功能。
中測(cè)試可以被自動(dòng)化也可以是手工的，他們通常包含兩個(gè)或多個(gè)功能，并特別的關(guān)注功能之間的交互。曾經(jīng)有SET把這種測(cè)試描述成“測(cè)試一個(gè)功能和它的近鄰”。對(duì)于一個(gè)產(chǎn)品的周期中，在單獨(dú)的各功能的實(shí)現(xiàn)過(guò)程這個(gè)階段，SET會(huì)驅(qū)動(dòng)這種測(cè)試的開(kāi)發(fā)（為了讓SWE能方便的編寫(xiě)“中測(cè)試”做準(zhǔn)備）；這種測(cè)試的大量編寫(xiě)、調(diào)試、維護(hù)工作則是SWE的事情。如果測(cè)試失敗，工程師會(huì)自己去搞定它。在開(kāi)發(fā)階段的后期，TE會(huì)手工執(zhí)行（當(dāng)這個(gè)測(cè)試不容易自動(dòng)化，或者自動(dòng)化的代價(jià)太大時(shí)）或自動(dòng)化的執(zhí)行他們。中測(cè)試要回答的問(wèn)題是一組鄰居功能是不是能完成他們應(yīng)有交互任務(wù)。
Large Tests。大測(cè)試覆蓋三個(gè)或更多的功能，并且要盡可能的代表真實(shí)的用戶(hù)場(chǎng)景。怎么來(lái)對(duì)一個(gè)集成了所有功能的場(chǎng)景來(lái)設(shè)計(jì)case這個(gè)或許有疑問(wèn)，大師大測(cè)試都是結(jié)果導(dǎo)向的，比如軟件是不是能有滿(mǎn)足用戶(hù)的預(yù)期？三個(gè)角色都會(huì)參與大測(cè)試的編寫(xiě)，從自動(dòng)化測(cè)試到探索性測(cè)試所有的事情都要完成。大測(cè)試要回答的問(wèn)題是：產(chǎn)品是不是完成了用戶(hù)預(yù)期的功能。 語(yǔ)言上的稱(chēng)謂具并不重要，重要的是Google的測(cè)試人員有這么個(gè)共同語(yǔ)言并且知道他們每個(gè)測(cè)試代表的范圍。當(dāng)一些激進(jìn)測(cè)試人員談?wù)摰谒念?lèi)測(cè)試的時(shí)候，他們值得實(shí)際上是一種能夠涵蓋所有功能的系統(tǒng)測(cè)試，而且這個(gè)測(cè)試要跑很長(zhǎng)的時(shí)間。
我們要測(cè)試什么以及測(cè)試多少，這后面的驅(qū)動(dòng)力量是動(dòng)態(tài)變化的，而且產(chǎn)品之間也有不同。Google更傾向于頻繁的發(fā)布，把產(chǎn)品推向用戶(hù)，然后從用戶(hù)收集反饋并迭代?；鞠敕ň褪且坏┪覀冮_(kāi)發(fā)了一個(gè)產(chǎn)品或一個(gè)現(xiàn)有產(chǎn)品的新功能，就立即把他推向用戶(hù)，這樣用戶(hù)就能第一時(shí)間從中受益。這就需要我們把用戶(hù)和外部開(kāi)發(fā)者在前期就納入進(jìn)來(lái)，這樣我們就能清楚我們做的東西是不是已經(jīng)達(dá)到目的了。
最后，對(duì)自動(dòng)化和手工測(cè)試的混合來(lái)說(shuō)，自動(dòng)化毫無(wú)疑問(wèn)是最推崇的，不管是在大中小的測(cè)試中。如果它能夠被自動(dòng)化，并且過(guò)程中不需要人的智慧和靈感的介入，它理所當(dāng)然要被自動(dòng)化。只有在需要人來(lái)做判斷的情況下才考慮手工來(lái)做，比如：UI的美觀性、暴露一些數(shù)據(jù)會(huì)構(gòu)成隱私問(wèn)題。 盡管說(shuō)了這么多，你必須要曉得Google要做大量的手工測(cè)試的，可能是寫(xiě)腳本方式也可能是探索性方式，但即便如此這些測(cè)試也是在自動(dòng)化的監(jiān)視下完成的——工業(yè)化的腳本錄制技術(shù)可以把手工測(cè)試轉(zhuǎn)換成自動(dòng)化測(cè)試腳本，這些腳本就可以在每次構(gòu)建后來(lái)執(zhí)行，以此來(lái)最小化回歸測(cè)試的開(kāi)銷(xiāo)，并且把人力集中到那些新問(wèn)題上。我們也自動(dòng)化了bug的提交和手工測(cè)試任務(wù)指派。比如：如果有個(gè)自動(dòng)化測(cè)試失敗了，系統(tǒng)會(huì)確定最后的代碼更改位置（這里最可能是出現(xiàn)問(wèn)題的地方），然后發(fā)郵件給其作者并記錄一個(gè)bug。The
ongoing effort to automate to within the “l(fā)ast inch of the human mind” is currently the design spec for the next generation of test engineering tools Google is building.（within在這里應(yīng)做動(dòng)詞“把XX融入”來(lái)講，大概意思是：正在努力的方向是“自動(dòng)化人類(lèi)的每個(gè)想法”，也就是人只要一想出來(lái)怎么測(cè)試，然后就可以立即把這個(gè)想法自動(dòng)化，這是Google在建設(shè)的下一代測(cè)試工具）
下一篇將是關(guān)于SET的工作的。
（六）SET的工作方式
SET是專(zhuān)注于測(cè)試的軟件工程師。他們是樂(lè)于編寫(xiě)測(cè)試功能的軟件工程師。首先說(shuō)，SET是開(kāi)發(fā)者，在招聘的時(shí)候我們就會(huì)說(shuō)這個(gè)工作是100%的編碼工作，晉升階梯中的描述也是如此。當(dāng)我們面試SET的時(shí)候，對(duì)于寫(xiě)代碼能力的要求跟SWE幾近相同，之外我們還會(huì)強(qiáng)調(diào)SET要懂得如何測(cè)試他們自己的代碼。換句話說(shuō)，SWE和SET都要回答編碼問(wèn)題，但是SET要面對(duì)更多的測(cè)試問(wèn)題。
你應(yīng)該猜到了，這個(gè)角色很難做，而且造成Google的SET數(shù)量很少的原因，可能完全不是因?yàn)槲覀冇嗅槍?duì)生產(chǎn)率的一套魔法公式，而在于：把我們的工程實(shí)踐應(yīng)用到SET技能的人真的很難找。我們優(yōu)化這項(xiàng)重要的工作并且圍繞這些人建立流程。
SET不會(huì)參加到前期的設(shè)計(jì)當(dāng)中，之所以如此不是我們有一這樣的，這是由我們的項(xiàng)目誕生方式來(lái)決定的。一個(gè)典型的新項(xiàng)目誕生情況就是：?jiǎn)T工的20%非正式時(shí)間的投入變成了Google自己品牌的項(xiàng)目。Gmail和Chrome OS都是這樣在一開(kāi)始沒(méi)有自上而下的一個(gè)任務(wù)指派，但是最終成長(zhǎng)為由很多開(kāi)發(fā)和測(cè)試工程師組成的團(tuán)隊(duì)來(lái)共同構(gòu)建的產(chǎn)品。在這樣的一種情況下，一開(kāi)始的開(kāi)發(fā)是不在乎質(zhì)量的，其目的在于驗(yàn)證一個(gè)概念，或者是專(zhuān)注可擴(kuò)展性、性能等一些在質(zhì)量成為問(wèn)題之前必須正確的東西。簡(jiǎn)單來(lái)說(shuō)，如果你不能夠使你的web
service能夠有擴(kuò)展性，那么測(cè)試問(wèn)題就顯然不是一個(gè)最大問(wèn)題（擴(kuò)展性才是）。
一旦確定一個(gè)產(chǎn)品能做、要做的時(shí)候，那么開(kāi)發(fā)團(tuán)隊(duì)就要開(kāi)始尋求測(cè)試的介入了。 關(guān)于這個(gè)流程你可以這么來(lái)想象：某人有了一個(gè)想法，首先要對(duì)其思考，然后寫(xiě)一下實(shí)驗(yàn)代碼，去征求其他人的想法，再寫(xiě)代碼改進(jìn)，找其他人一起來(lái)做，再寫(xiě)更多的代碼，之后他們意識(shí)到他們的這個(gè)想法非常有價(jià)值，進(jìn)而寫(xiě)更多的代碼來(lái)實(shí)現(xiàn)他們的想法并把實(shí)現(xiàn)出來(lái)的效果給更多的人看，并收集反饋，這個(gè)時(shí)候這個(gè)項(xiàng)目其實(shí)就已經(jīng)放入了Google的項(xiàng)目數(shù)據(jù)庫(kù)了，項(xiàng)目也變成了真正的項(xiàng)目。一個(gè)項(xiàng)目在沒(méi)到達(dá)這個(gè)階段前，是不會(huì)有測(cè)試人員介入的。
所有的項(xiàng)目都會(huì)有測(cè)試人員么？默認(rèn)不會(huì)。小項(xiàng)目還有那些只對(duì)有限的一些用戶(hù)有用的項(xiàng)目都是由開(kāi)發(fā)那些項(xiàng)目的工程師自己來(lái)測(cè)試的。其他那些對(duì)用戶(hù)和公司更具風(fēng)險(xiǎn)的才會(huì)引起測(cè)試的注意。
開(kāi)發(fā)團(tuán)隊(duì)任務(wù)是向測(cè)試人員尋求幫助，向測(cè)試人員證明他們的項(xiàng)目是多么的刺激和充滿(mǎn)潛力。開(kāi)發(fā)的負(fù)責(zé)人向測(cè)試負(fù)責(zé)人講解項(xiàng)目的想法、進(jìn)展和發(fā)布計(jì)劃，測(cè)試負(fù)責(zé)人則要就“測(cè)試工作如何分擔(dān)”“SWE參與測(cè)試”“預(yù)期的單元測(cè)試級(jí)別”“發(fā)布中的責(zé)任如何分擔(dān)”等問(wèn)題展開(kāi)商討。SET可以在項(xiàng)目一開(kāi)始不介入，但是一旦正式立項(xiàng)，在項(xiàng)目如何來(lái)實(shí)施這個(gè)問(wèn)題上，則有巨大的影響力。
當(dāng)我說(shuō)“testing”這個(gè)詞的時(shí)候，我指的不單單是運(yùn)行代碼，覆蓋代碼路徑。測(cè)試人員不一定從一開(kāi)始就介入，但測(cè)試（testing）卻是（作者的意思是測(cè)試其實(shí)是無(wú)處不在，從項(xiàng)目一開(kāi)始的各種工作都會(huì)與測(cè)試有多多少少的聯(lián)系，比如后面說(shuō)的提交代碼，這里testing如果換成QA可能更有利于國(guó)內(nèi)的一些業(yè)內(nèi)人來(lái)理解）。事實(shí)上，（請(qǐng)注意）一個(gè)開(kāi)發(fā)即便是在提交代碼的時(shí)候都會(huì)感覺(jué)到SET的存在。 （七）TE的工作
相比SWE和SET，TE在Google是一類(lèi)新職位。因此，這個(gè)職位的角色定義還在進(jìn)行中。當(dāng)前Google的這代TE正在為這個(gè)職位開(kāi)辟一條道路，這樣就能更好的指導(dǎo)后面招聘進(jìn)來(lái)的TE來(lái)開(kāi)展工作。我們這里描述的是在Google新興起來(lái)的一個(gè)最好過(guò)程（It is the process
that is emerging as the best within Google that we present here）。
并不是每個(gè)項(xiàng)目都需要TE。那些在產(chǎn)品初期的實(shí)驗(yàn)性嘗試，沒(méi)有良好定義的任務(wù)或用戶(hù)場(chǎng)景的項(xiàng)目勢(shì)必不會(huì)引起很TE的注意。如果一個(gè)產(chǎn)品看起來(lái)沒(méi)什么希望（作為一個(gè)概念他不能通過(guò)審核）或者尚未能吸引用戶(hù)注意或者沒(méi)有清晰的功能定義（原文是have a well defined set of
features，懷疑是作者落下了not，從上下文判斷應(yīng)該是not have a well defined set of features），測(cè)試工作就應(yīng)該是開(kāi)發(fā)他的人自己來(lái)做。
即便對(duì)于一個(gè)確定要對(duì)外發(fā)布的產(chǎn)品，TE在開(kāi)發(fā)階段的初期也沒(méi)什么事情可做，因?yàn)樵谶@些階段功能在不斷變動(dòng)，最終的功能和邊界也不確定。在測(cè)試方面太早的投入過(guò)多就會(huì)導(dǎo)致很多工作被丟棄（因?yàn)楫a(chǎn)品的功能可能后來(lái)就變了）。同理，一開(kāi)始做測(cè)試計(jì)劃需要的TE數(shù)量比后期做探索性測(cè)試TE數(shù)量少很多，因?yàn)椋搅撕笃诋a(chǎn)品幾近成型，這個(gè)時(shí)候?qū)ふ疫z漏bug顯得非常緊急。
在一個(gè)項(xiàng)目中配備TE跟風(fēng)險(xiǎn)和ROI息息相關(guān)。對(duì)于客戶(hù)和企業(yè)來(lái)說(shuō)這意味著要花更多的測(cè)試精力同時(shí)需要更多TE。但是這種努力需要和回報(bào)成比例。我們需要正確數(shù)量的TE在正確的時(shí)間并起到正確的作用。
一旦介入，TE并不是一切從頭開(kāi)始來(lái)。因?yàn)橐呀?jīng)有SWE和SET做了大量的測(cè)試工程化和面向質(zhì)量的工作，這些工作都是TE后續(xù)工作的基礎(chǔ)。TE的初期介入要做的事情有：
所有的這些都在質(zhì)疑要發(fā)布軟件的風(fēng)險(xiǎn)輪廓。TE并不需要親自做所有的這些工作，但是他要確保這些事情都做了，并利用別人的工作來(lái)評(píng)估是不是還有更多需要做的事情?？偟膩?lái)說(shuō)，TE對(duì)企業(yè)的價(jià)值體現(xiàn)在他保護(hù)用戶(hù)和公司免受一系列問(wèn)題的侵?jǐn)_，比如壞的設(shè)計(jì)、令人困惑的UI、功能bug、安全和隱私問(wèn)題等。在Google，TE是一個(gè)團(tuán)隊(duì)中唯一個(gè)全職的從整體上來(lái)關(guān)注產(chǎn)品和服務(wù)弱點(diǎn)的人。因此，TE的職業(yè)路線相比SET來(lái)說(shuō)遠(yuǎn)沒(méi)有規(guī)則和格式可循。在項(xiàng)目的任何階段都有可能需要TE的協(xié)助，從創(chuàng)意階段到好幾個(gè)版本發(fā)布，甚至是監(jiān)視一些過(guò)時(shí)的、封存的項(xiàng)目。通常，一個(gè)TE會(huì)同時(shí)服務(wù)于多個(gè)項(xiàng)目，特別是那些有特殊技術(shù)（比如安全）TE。
顯然，不同項(xiàng)目中TE要做的事情可能差別蠻大的。有些TE要花大量的時(shí)間寫(xiě)代碼，有點(diǎn)像SET，只不過(guò)重心是關(guān)注終端用戶(hù)的使用場(chǎng)景。還有些TE針對(duì)現(xiàn)有的代碼和設(shè)計(jì)從中尋找故障失敗模式和導(dǎo)致故障的原因，這種情況下，TE可能會(huì)修改代碼但是不會(huì)從頭寫(xiě)。TE在做測(cè)試計(jì)劃的時(shí)候必須更系統(tǒng)、全面，并在真正使用（系統(tǒng)）和系統(tǒng)經(jīng)驗(yàn)方面兼顧完整性。TE擅長(zhǎng)處理需求中的模糊性，并且善于推理和表達(dá)邏輯問(wèn)題。
成功的TE在敏感的、有時(shí)候個(gè)性很強(qiáng)開(kāi)發(fā)、產(chǎn)品團(tuán)隊(duì)之間游走過(guò)程中完整所有任務(wù)。每當(dāng)他發(fā)現(xiàn)漏洞，TE高興的攻破系統(tǒng)，并驅(qū)動(dòng)SWE、PM、SET去解決這些問(wèn)題。
這樣的一個(gè)職位描述可能讓他的前景有點(diǎn)嚇人，他需要各種知識(shí)的融合包括技術(shù)方面的、領(lǐng)導(dǎo)力方面的、產(chǎn)品理解方面的，如果沒(méi)有合適的指導(dǎo)，這個(gè)職位很可能會(huì)失敗。但在Google，強(qiáng)大的TE社區(qū)已經(jīng)出現(xiàn)來(lái)對(duì)付這種情況。在所有的職位中，TE可能是最注重支持（peer supported）的這么一個(gè)角色，做好TE這個(gè)職位需要的洞察力和領(lǐng)導(dǎo)力通常意味著很多的測(cè)試經(jīng)理都是從TE這個(gè)職位里走出來(lái)的。 Google的TE工作的流動(dòng)性掩蓋了各種程式化的介入過(guò)程（言外之意就是TE的工作很靈活不確定，原文是：belies any prescriptive process for engagement）。TE可以在任何時(shí)間點(diǎn)介入項(xiàng)目，并且必須要迅速的評(píng)估項(xiàng)目的狀態(tài)、代碼、設(shè)計(jì)和用戶(hù)，還要確定什么是首要關(guān)注的東西。如果項(xiàng)目是剛開(kāi)始啟動(dòng)，測(cè)試計(jì)劃通常首要考慮的事情。有的時(shí)候TE會(huì)在項(xiàng)目的末尾階段被拉來(lái)評(píng)估項(xiàng)目是不是適合發(fā)布，或者一個(gè)早期的Beta版被放出的話會(huì)不會(huì)有問(wèn)題。如果TE來(lái)到的是一個(gè)新應(yīng)用或者是一個(gè)他之前沒(méi)有任何經(jīng)驗(yàn)的應(yīng)用，他們就會(huì)從一些探索性測(cè)試開(kāi)始做起，基本沒(méi)有什么規(guī)劃。還有的情況是項(xiàng)目很久沒(méi)有發(fā)布了僅需要一些（安全）修復(fù)，或者界面交互的調(diào)整，這對(duì)TE來(lái)說(shuō)就需要一些不同的策略?？傊痪湓?，在Google中TE的工作沒(méi)有定式可循。
|
|
|
來(lái)自： yzqwqp > 《測(cè)試相關(guān)》
