前段時間比較迷茫，沒有明確的學習方向和內容。不過有一點應該是可以肯定的：迷茫的時候就把空閒的時間用來看書吧！
這本書，目前只是比較粗略的看了一遍，感觸很大。以下是個人所作的筆記，與原文會有出入的地方。建議感興趣的夥伴閱讀原文書籍！
一、質量不等於測試
質量不是被測出來的：未經測試也不可能開發出有質量的軟體。
保證質量：
測試開發同時開展：google目標。
開發對質量的責任：寫一段程式碼後立刻測試，完成了更多的程式碼就做更多的測試；質量像是預防行為（質量是開發過程的問題，不是測試問題）。
測試：線上bug重重，就會回滾版本；判斷預防工作做得怎麼樣（開發的測試，能不能確保不會出現回滾級別的bug發生）。
二、角色
1、軟體開發工程師SWE：
實現終端使用者所使用的功能程式碼：
建立設計文件、選擇最優的資料結構和整體架構、程式碼實現和程式碼稽核。
編寫測試程式碼：
測試驅動的設計、單元測試、參與構建各種大小規模的測試。
增加功能性程式碼或是提高效能的程式碼。
質量責任：
對他們編寫、修復以及修改的程式碼承擔質量責任（容錯設計、故障恢復、測試驅動設計、單元測試）。
2、軟體測試開發工程師SET：
工作重心：
保證SWE開發的功能模組具有可測試性：參與設計評審，觀察程式碼質量與風險；可能會重構程式碼，編寫單元測試框架和自動化測試框架。
通用測試基礎框架。
負責提供測試支援：
有個測試框架：可以把新開發的程式碼隔離，通過模擬真實的工作執行環境和程式碼提交佇列來管理程式碼的提交。
關注：質量提升和測試覆蓋率的增加。
寫程式碼的目的：可以讓SWE測試自己的功能。
3、測試工程師TE
專注使用者角度的測試：
花大量時間模擬使用者的使用場景和自動化指令碼或程式碼的編寫上。
是否滿足效能期望，在安全性、國際化、訪問許可權等方面是否滿足使用者的要求。
工作：
組織整體質量實踐（把SWE和SET編寫的測試分類組織起來），分析解釋測試執行結果，驅動測試執行，構建端到端的自動化測試。
三、組織結構
大多數公司：
資深管理者一般來自產品經理或開發經理，而不是來自測試團隊。
產品釋出時，優先考慮的是功能是否完整和易用性方面是否足夠簡單，很少考慮質量。
作為同一個團隊，測試總是在為開發讓路：“行業充斥著各種有缺陷、早產的產品”的問題所在；質量不行就再釋出一個補丁包。
Google組織彙報關係：
劃分不同的專注領域：客戶端、地理、廣告等（開發工作彙報給這些專注領域的管理者）。
測試是獨立存在的部門：工程生產力團隊
- 以租借的方式進入產品團隊：
1) 做提高質量的相關工作，或者公開一些不可接受的缺陷率資料；
2) 不是直接向產品團隊進行彙報，不能因專案急需釋出就能通過測試（可以事先協商。有自己選擇決定的優先順序，在可靠性、安全性上的問題不會妥協）；
3) 可以讓SET和TE保持新鮮感和忙碌，一個好的想法可以快速在公司內部蔓延
- 會根據不同產品團隊的優先順序、複雜度，並與其他產品實際比較之後，再來分配測試人員(可能會搞錯，但總體上來說會保持實際需求與不明確需求之間的某種平衡)。
四、爬走跑
1、Google產品經常在最初版本里只包含最基本的可用功能
在後續的快速迭代中得到內部和外部使用者的反饋。
每次迭代都非常注重質量。
產品釋出前，會經歷金絲雀、開發、測試、beta或正式釋出版本。
2、金絲雀版本
每日要構建的版本（核心開發團隊成員都會安裝）：
這個版本可能無法使用應有的基本功能；
安裝了錯誤程式碼，手機甚至無法使用基本功能；
用來排除過濾明顯不適宜的版本：
構建失敗，意味著流程可能出現嚴重問題
3、開發版本
每週釋出，該版本有一定功能並通過一系列測試：產品相關工程師會安裝。
不能滿足日常真實工作需求，會打回金絲雀版本：工程團隊會花時間重新評估。
4、測試版本
通過了持續測試，近一月裡的最佳版本。
有持續的優良表現，會作為beta測試的候選版本。
5、beta或釋出版本
對外發布的第一個版本：經歷了內部使用和通過所有質量考核。
五、測試型別
使用稱謂：小型測試、中型測試、大型測試。
強調測試的範疇規模而非形式；規模越小，越可能被實現成自動化的測試。
1、小型測試
驗證一個單獨函式或獨立功能模組的程式碼是否按預期工作。
一般是自動化實現：
幾秒或更短的時間就能執行完畢。
SWE實現，也會有少量SET參與。
使用mock，在fake（虛假實現）環境中執行。
2、中型測試
驗證功能模組間的互動和彼此呼叫時的功能是否正確。
通常也是自動化實現：
獨立模組開發完後，SET會驅動這些測試的實現及執行，SWE會深度參與，一起編碼、除錯維護這些測試。
執行失敗，SWE會自覺去檢視分析原因。
開發後期，TE會通過手動的方式或自動化執行這些用例。
一般執行在虛假實現（fake）環境或真實環境中。
3、大型測試
涵蓋多個模組，關注所有模組的整合，傾向於結果驅動，驗證軟體是否滿足終端使用者的需求。
或是通過自動化，或探索式測試：三種工程師都會參與；需要消耗數個小時或更長時間。
一般執行在真實環境中，並使用真正的使用者資料和資源