目錄
前言
在職業生涯的頭6年，我對所謂的測試策略、測試組織架構瞭解甚少，也不知道誰對誰錯。我知道的事情只有一個：我是一名程序員，我的日常工作除了做需求分析和代碼開發以外，我還需要做單元測試（數據準備、案例編寫和測試報告撰寫）、SIT測試（數據準備、案例編寫和報告撰寫）及UAT測試支持（數據準備）。簡而言之，就是我們一個小團隊，就是一幫開發工程師相互配合，組長負責進度質量把控與需求分析，下面的開發人員負責各自模塊的開發與測試，團隊成員之間會進行互測和代碼審查以保證質量。但是，我認爲正是這種貌似不嚴謹實則更科學合理的分工恰恰讓我們培養起做事嚴謹、設計全面（特別是非功能性，如可測試性、可運維性等）的態度。
今天，回顧在前司的工作跟《Google軟件測試之道》這本書在某種程度上是不謀而合的。
1、Google軟件測試介紹
- Google成功的關鍵是什麼？作者的第一個建議就是不要招聘太多的測試人員。
- Google的測試團隊更像小而精的特種部隊，我們依靠的是出色的戰術和高級武器。
- 在Google，寫代碼的開發人員也承擔了質量的重任，開發者本身就是測試者。
- 質量不等於測試。當你把開發過程和測試放到一起，就像在攪拌機裏混合攪拌那樣，直到不能區分彼此的時候，你就得到了質量。
2、角色
You build it , you break it , you fix it.離故障和缺陷最近的人絕對是開發人員，因此只有或者應該由開發人員才能修復。在Google分爲三種角色：
1、軟件開發工程師（SWE, Software Engineer），傳統意義上的開發人員，負責所有業務功能的實現，創建設計文檔、數據字典、接口文檔，並花大量時間在代碼實現及審查這兩方面；同時他也要負責單元測試工作，及參與各種各樣的測試工作（如類似的集成測試等）；
2、軟件測試開發工程師（SET, Software Engineer in Test），他也是一個開發角色，只是工作重心會在代碼的可測試性和基礎的通用測試框架上。他們會參與項目的設計評審，更有甚者對負責對代碼進行重構以便增加代碼可測試性。SET是SWE在代碼庫層面的合作伙伴，只是SET會更關注整體質量提升及測試覆蓋率的提高，而SWE會更關注業務功能的實現，這就是這兩者的區別。
3、測試工程師（TE, Test Engineer），TE把用戶放在第一位來思考；他們會組織整體質量實踐，分析解釋試運行結果，驅動測試執行，構建端到端的自動化測試。他們是真正的產品專家、質量顧問和風險分析師。
3、分工
從上述三種崗位職責基本可以看出來他們是如何配合：
首先，SWE會根據業務需求編寫代碼實現業務功能；但是做過很多年開發的同學也知道，代碼中含有的功能（這裏稱“代碼功能”）應該是業務功能和非業務功能（如容錯性代碼、運維輔助性代碼、測試輔助性等）的總和。因此，需要SET提供測試支持，如建立測試框架保證通用測試能力，參與項目的設計評審，在測試角度(非開發角度)去審覈代碼與設計方案以確保方案或者代碼的可測試性，這樣即可實現真正意義上的獨立功能模塊的要求（因爲測試案例也是基於獨立功能模塊的邊界去設計的），後面的模塊遷移可以做到功能代碼和測試代碼的共同遷移；
接着，在我看來，TE的工作主要分爲兩個階段，即集成測試後期與用戶測試（雖然Google裏面沒有SIT和UAT一說）。在SIT後期階段，TE會通過SWE和SET在前面階段產生的測試數據進行統計分析，並根據分析結果要求團隊進行相應改進，這一階段他負責整體的交付質量；在UAT階段，TE會作爲其中的用戶測試人員參與，過程中除了考慮用於體驗和使用場景外，TE也會考慮性能、安全、國際化等問題。
另外在分工方面，Google的很多項目中，其實測試人員多樣化實踐也確實做得不錯，諸如合同編制的測試人員、衆包形式參與的測試者、內部嚐鮮者、beta測試者及早期用戶，正因爲測試用戶羣體廣泛性帶來的觀念、目的、使用習慣等因素的多樣性，才保證了測試的有效性，而這個有效性不是純在於對功能需求的100%匹配，而是更在於儘早發現不符合用戶期望的東西並剔除掉。
4、組織架構
Google的測試是作爲獨立的部門而存在的，與各個專注於各領域的業務條線部門平行，測試組織被稱爲工程生產力團隊。在每個項目中，測試人員是以租借的形式進入產品團隊，去做提高質量相關的事情。因爲測試人員並不是直接向產品團隊彙報，因此在發佈流程中測試並不是一個被通知的角色。他們有自己的優先級，在安全性、可靠性等問題上不會妥協，除非碰到更重要的事情，但是該事情必須得與測試部門提前溝通。
正因爲上述的組織架構，才保證了測試團隊的人員數量控制在數量較少規模。同時，測試團隊會要求產品團隊不能降低要求來招聘更多的測試人員，從而讓他們做一些簡單重複瑣碎的髒活累活，這樣則反向要求開發人員對自己的交付有一定的要求，而不是隨便寫完代碼就丟給測試人員去測，這樣對開發人員反而是一種測試能力和開發素養上的培養。
5、版本
Google的發佈過程雖然快，但是實際上在正式發佈前還是經歷了一系列的內部版本驗證過程以證明它已經具備一定的質量。主要分爲以下的順序：
1、金絲雀版本：
這是每天構建的版本，用於排除一些有明顯不適宜的版本。一般來說，只有該產品的工程師和管理人員使用。
2、開發版本：
這是開發人員日常使用的版本，每週發佈一個。該版本相比金絲雀版本較爲穩定並且要求該產品下面的工程師在日常真實工作中強制使用。
3、測試版本：
該版本應該是最近一個月的最佳版本，也是最穩定最合適的一個版本。同時也作爲內部嚐鮮版給內部嚐鮮者使用，如果該版本有持續的良好表現即可能被作爲beta測試的候選版本。
4、beta或發佈版本：
該版本由非常穩定的測試版本演變而來，並且經理內部使用和通過所有質量考覈，因此也是對外發布的第一個版本。
Google裏面的這種爬、走、跑的模式，能夠爲應用程序儘早提供一個測試驗證的機會，與從自動化測試反饋一樣，每天都能從用戶那裏得到有用的反饋。