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