目錄
1、“烏托邦式”軟件開發過程
在理想的情況下，TDD模式先行，即在代碼編寫前開發人員會構思好整個代碼邏輯並編寫成僞代碼（當然僞代碼中包含了數據取值邊界，循環嵌套，異常處理等情況），然後根據僞代碼編寫單元測試腳本，最後根據單元測試腳本編寫業務代碼並運行之。最後，如果運行通過則大功告成，一切美妙而順暢，我稱之爲“烏托邦式”軟件開發。
在這樣理想的環境下，人的思維模式會隨着崗位的不同而略顯差異。對於功能代碼開發人員來說：思維模式是創建，重點在於構建業務功能並儘快交付，因此其測試模式爲建設性測試；對於測試開發人員來說：思維模式則是破壞，重點在於打破其業務邏輯與數據流，因此其測試模式爲破壞性測試。但是兩者不會把用戶體驗放在首位，因此這裏需要第三種開發人員“用戶開發人員”，他們聚焦於用戶場景、用戶體驗、探索性測試等活動，他們考慮的是端到端的整體能否給用戶帶來價值，這裏我稱之爲“理想”的三劍客模式。
對Google來說，這三種角色是跟“三劍客”模式比較相似，這就是上篇文章中提到的SWE、SET、TE。
SWE：代碼開發人員，負責功能模塊開發及相應的單元測試活動；
SET：測試開發人員，部分負責在代碼開發人員的單元測試中提供支持，另一部分則爲代碼開發人員提供測試框架，以便進行更多質量相關的測試工作；
TE：即用戶開發人員，負責從業務角度思考開發質量的各種問題，他們也負責編寫部分的自動化用例代碼，也參與評估整體代碼的覆蓋率。
2、SET的工作
實際上，整個開發流程中SET和SWE是緊密配合的夥伴，雖然日常工作有所重疊，但是Google是這樣認爲的：測試工作是由整個工程團隊負責，而不僅僅單獨由那些頭銜上帶着“測試”的工程師來負責的。
代碼的組織形式、開發過程、維護是日常的工作重點。Google使用統一的工具，這樣可以最大程度降低團隊成員在不同項目切換的學習成本，而且Web應用開發人無須申請任何權限即可查看其他團隊編寫在類似場景寫下的代碼，同時在代碼庫工具中提供了諸如搜索的便利功能。應該這樣說：公開的代碼庫、和諧的工程工具、公司範圍內的資源共享，成就了豐富的Google內部共享代碼庫與公共服務。
針對這個這些共享的代碼，Google內部形成了一套不成文的實踐：
- 所有工程師必須複用已經存在的公共庫，除非在項目特定需求方面有很好的理由；
- 對於共享代碼，首先要考慮的是能否可以容易找到，並具有良好的可讀性；
- 共享代碼必須儘可能被複用且相對獨立；
- 所有依賴必須明確指出，不可被忽視。即這些共享代碼在沒有知會其他引用它的項目團隊或工程師前是不允許被修改；
- 如果一個工程師對共享代碼有優化方案時，他需要去重構已有代碼併爲其他引用它的應用進行遷移提供支持；同時，該“善舉”是被鼓勵的。如Google的"同僚獎金（peer bonus）"，這樣做的目的可以讓該“善舉”形成良性循環。
- Google非常重視代碼審查，特別針對共享代碼必須通過相關的可讀性審覈，並且在通過審覈後工程師被授予“良好可讀性”證書。另外，內部建有可讀性方面的代碼風格指南。
- 共享代碼對測試有着更高的要求。
Google內部有一種（peer bonus）制度，這是爲他人申請小額獎金的制度。不管是在同一個部門還是在不同的部門，只要這個人給自己很大的幫助，或是因爲有他的默默努力公司變得越來越好，就可以幫他申請這份對等獎金。我認爲這是一種很好的制度，它能孕育出發現他人的優點並積極主動地去感謝這一美德。
首先，SET是名100%的編碼角色，是名軟件工程師，這個角色設定的特別之處在於該崗位使得測試方式可以讓測試人員儘早接入到開發流程，但不是通過所謂的“質量模型”和“測試計劃”的方法，而是通過參與設計和代碼開發的方式。
- SET與SWE處於相同的地位，他積極參與各類測試活動，如手動測試和探索性測試等，也會參與SWE的代碼評審（因爲SET的另外一個考覈就是必須瞭解如何去測試他們編寫的代碼）；因爲在Google看來，測試也是應用產品的另外一種功能，而SET則是這個功能的負責人。
- 另外，Google也從物理位置上讓SET與SWE坐在一起，方便互相學習互相借鑑。正是這樣的組合一起構成了Google最有效率的工程產品團隊。
以下以軟件開發的過程對SET的工作進行介紹：
1、項目早期階段
在項目早期階段測試一般不會介入，這個在傳統眼光看來可能會有點核突，可能這跟Google的文化及非正式的創新驅動產品的流程約束有關。大家一定聽過Google的工程師是有20%的時間用於做自己的事情，且Google的很多創新產品也是來自於那20%。因爲在Google看來，在一個產品如果在概念都沒完全成型時就去關心質量，這就是優先級混亂的表現。
針對上面這段體會我有兩點的感受：
1、我真的很羨慕那20%，最近幾個月我一直在做DevOps方面的學習，也把部分所掌握的應用到日常工作中，但是遺憾的是這些時間都是晚上擠出來的，因此推進比較慢；在支撐我做這個的原因不外乎兩個：1）想改善工作中的某些東西；2）興趣所致；
2、關於“優先級混亂”這個事情，我還是那句老話：任何事情合不合理要看當時的上下文。因爲Google是互聯網公司，天生就是短平快，對質量的考量在某種類型產品在某個特定時間域內確實是沒毛病的；但是換成是銀行，特別是涉及到動賬類交易的話，質量則無論如何都是first priority，這是沒得商量的。因此我認爲上述這句話沒有對錯，只有是否適用。大家也不必視爲聖經。
2、設計階段
所有的Google項目都有設計文檔，而且文檔中會囊括所有將來需要完成的工作清單，也作爲項目前進的路標。
在項目初期，在SWE完成設計文檔的初稿併發送給更大範圍人做正式評審前會請求SET的反饋。因爲：
1、SET需要熟悉瞭解對應的系統設計；
2、SET早期的建議能夠馬上反饋並更新到文檔上，這樣也增強了SET在團隊中的影響力；
3、對於SET來說，這是一個可以在項目初期快速建立與開發工程師的良好工作關係的好機會。
並在審覈過程中，SET一般是帶着一定的的目的性，需要完成特定的目標；Google建議從以下幾個維度進行審覈：
- 完整性 - 鼓勵文檔編寫者通過添加更多細節或外部鏈接以便補充背景知識，方便新人快速瞭解；
- 正確性 - 注意文檔編寫的語法、文字等準確性，注意嚴謹性；
- 一致性 - 確保配圖與文字描述一致性；
- 設計 - 文檔中的一些設計需要經過深思熟慮，要考慮到設計所需的前置條件是否滿足；
- 接口與協議 - 接口協議是否定義清晰（如接口文檔是否都清晰描述了每個字段的格式、長度【字符還是字節】、是否支持爲空、是否有缺省值、是否描述清楚支持中文或英文、跟其他字段是否有關聯組合值關係、等等）
- 測試 - 文檔描述的整個系統的可測試性如何？是否需要增加testing hook，是否需要新增一些內部接口用於服務可測試性？（請永遠記住可測試性也是系統非功能性需求的其中一個需求）
3、集成測試前置階段
爲了能夠儘早可以運行集成測試，SET在設計文檔（特別是接口文檔）都基本定版的情況下，會開始針對各個模塊的依賴（接口依賴）編寫相應的mock或fake代碼。有時候，在SWE還沒完成業務模塊代碼編寫完成前，其對應的mock或fake已經完成。
4、自動化測試階段
在自動化測試方面，Google是這樣建議的：儘早給SWE提供一個可實施的自動化測試框架及計劃是一個很好的解決方案，但是一味追求100%覆蓋的自動化卻是不切實際的，因爲全覆蓋意味着維護工作量大及難度大。（其實這個在我看來就是二八原則）
在Google，SET在這個階段要準備以下工作：
1、把容易出錯的接口通過mock或者fake進行隔離，確保良好的覆蓋率；
2、構建一個輕量級的自動化框架，控制mock系統的構建與執行；
3、構建一個報表或儀表盤，以確保該系統的質量方面的數據是公開給所有關心的人，同時信息獲取的成本是很低的。