《Google軟體測試之道》—第1章1.2節角色

本節書摘來自異步社群《google軟體測試之道》一書中的第1章1.2節角色，作者【美】james whittaker , jason arbon , jeff carollo，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

1.2　角色

為了保證“解鈴還需系鈴人”這句名言成為事實（譯注：“you build it，you break it”，摘自“you build it，you break it，you fix it”。原意指在建構實驗室（build lab）的人永遠不會去修複建構失敗（build break）的問題，隻有開發人員自己才能修複。這裡的意思是開發人員自己要對自己寫的代碼負責，比專職的測試人員更适合做測試工作。在傳統的開發崗位之外我們又增加了幾種角色。我們明确地提出了有一種工程師角色必須存在，他可以讓開發人員更加有效且高效地做測試。在google，我們的确建立了這樣的角色，他的職責就是讓其他的工程師更有效率和品質意識。這些角色常把他們自己看做是測試者，但實際上他們的使命是提高生産率。測試人員的存在是為了讓開發人員的工作更有效率，并且很大一部分展現在避免因馬虎粗心而導緻的返工，是以，品質也是效率的一部分。在接下來的章節裡，會花費較多的内容來詳細講解這些角色，是以在這裡隻進行簡單的介紹。

1.2.1 軟體開發工程師（swe）

軟體開發工程師（譯注：software engineer，後文簡稱swe）是一個傳統上的開發角色，他們的工作是實作最終使用者所使用的功能代碼。他們建立設計文檔、選擇最優的資料結構和整體架構，并且花費大量時間在代碼實作與代碼稽核上。swe需要編寫與測試代碼，包括測試驅動的設計、單元測試、參與建構各種大小規模的測試等，這些測試會在本章的後面做詳細解釋。swe會對他們編寫、修複以及修改的代碼承擔品質責任。假設一個開發者不得不修改一個函數，如果這次修改導緻已有測試用例運作失敗，或者需要增加一個新的測試用例，他就必須去實作這個測試用例的代碼。開發工程師幾乎将所有的時間都花費在了代碼編寫上。

1.2.2 軟體測試開發工程師（set）

軟體測試開發工程師（譯注：software engineer in test，後文簡稱set）也是一個開發角色，隻是工作重心在可測試性和通用測試基礎架構上。他們參與設計評審，非常近距離地觀察代碼品質與風險。為了增加可測試性，他們甚至會對代碼進行重構，并編寫單元測試架構和自動化測試架構。set是swe在代碼庫上的合作夥伴，相比較swe是在增加功能性代碼或是提高性能的代碼，set更加關注于品質提升和測試覆寫率的增加。set同樣會花費近百分之百的時間在編寫代碼上，他們這樣做的目的是為品質服務，而swe則更關注客戶使用功能的開發實作上。

注意

set是swe在代碼庫上的合作夥伴，與增加功能性代碼或提高性能的代碼的swe相比，set更加關注于品質的提升和測試覆寫率的增加。set寫代碼的目的是可以讓swe測試自己的功能。

1.2.3 測試工程師（te）

測試工程師（譯注：test engineer，後文簡稱te）是一個和set關系密切的角色，有自己不同的關注點——把使用者放在第一位來思考，代表使用者的利益。一些google的te會花費大量時間在模拟使用者的使用場景和自動化腳本或代碼的編寫上。同時，他們會把開發工程師和set編寫的測試分門别類地組織起來，分析、解釋、測試運作結果，驅動測試執行，特别是在項目的最後階段，推進産品釋出。te是真正的産品專家、品質顧問和風險分析師。某些te需要編寫大量的代碼，而另外一些te則隻用編寫少量的代碼。

te把使用者放在第一位來思考。te組織整體品質實踐，分析解釋測試運作結果，驅動測試執行，建構端到端的自動化測試。

從品質的角度來看，swe負責功能實作和這些獨立功能的品質。他們對容錯設計、故障恢複、測試驅動設計、單元測試負責，并和set一起編寫測試代碼。

set也是開發人員，負責提供測試支援。有這樣一個測試架構，它可以把新開發的代碼隔離，通過模拟一個真實的工作運作環境（一個包含stubs、mock、fake等方法的流程，這些内容會在後面詳細講到）和代碼送出隊列來管理代碼的送出。換句話說，set編寫代碼，通過這些代碼提供的功能讓swe能夠自己測試他們的功能。多數測試代碼是由swe完成，set存在的目的就是保證這些功能子產品具有可測試性，并且相應的swe還可以積極地參與到測試代碼的編寫中去。

很明顯，set的主要關注對象就是開發人員。set的主要職責是讓開發者可以很容易地編寫測試代碼，進而達到獨立功能子產品的品質要求。專注于使用者角度的測試則是te的職責。考慮到swe和set已經做了足夠多的子產品級别與功能級别的測試，下一步要考慮的就是要驗證這些可執行的代碼與資料內建在一起之後，是否可以滿足最終使用者的需求。在這裡，te扮演着一個雙重确認的角色，确認開發人員在測試方面的工作是否到位，任何明顯的bug都會表明早期開發人員所做的測試工作存在不足或比較馬虎。當這些明顯的bug變少時，te會把注意力轉移到常見使用者使用場景中去，是否滿足性能期望，在安全性、國際化、通路權限等方面是否滿足使用者的要求。te運作許多測試的同時，也負責和其他團隊的te、合同工編制的測試人員、以衆包形式參與的測試者、内部嘗鮮者、beta測試者以及早期使用者進行合作交流，與各方讨論基本設計帶來的風險、功能邏輯複雜性和錯誤避免的方法。一旦te參與到項目之中，基本上就會沒完沒了。