這本書的作者是在軟體測試界很有名的 James Whittaker，以 How to break xxx 系列跟 Exploratory Testing 聞名。這本是他在Google期間完成的著作。可惜他己經在2012年３月左右離開了Google，發表了一篇Why I left google/中文翻譯。從微軟到Google，最後又回鍋到微軟了。文中大體的原因就是Google把創新精神丟掉，而只專注在廣告上，不再是一家是以技術優先導向的公司。但是這些還是毫不影響Google在軟體界的王者地位。

Google跟微軟在軟體測試上的策略很不一樣。傳統上，微軟的開發與測試人員比例大概是１：１左右。小弟的公司也是如此。但是Google專職在測試的人員，就明顯少得很多。我想從本書找到，如果專職測試人員少的話，那麼整個軟體開發流程會變的如何？其實，微軟在2008年也有出一本拿自己公司名稱當招牌的測試書 How We Test Software at Microsoft，這本有點厚，之後找個機會來看。以目前軟體公司的發展看來，也許之後就會看到一本以 Facebook 為主角的測試書了。

Ch1. Introduction to Google Software Testing

• 在 Google，測試工作是由一個中央的組職稱為 Engineering Productivity 來負責。包含 Developer 跟 Tester tool chain, Release engineer 。從 Unit test 包到 Exploratory testing。

• Google 在2001年時，約有200位開發工程師，但是只有3位測試工程師，那時開發工程師就必需為自己寫的程試的品質負責。那時TDD跟JUnit才準備流行，所以測試主要以 ad-hoc 為主。

• James 常給人的忠告︰「不要顧用太多測試員工」，Larry Page︰「Scarcity brings clarity (意指︰在缺乏資源的情況時，會有清楚的目標；銀彈不足，才會想辦法彈無虛發)」

• Everyone who writes code is tester

問題︰但是人少，所扮演的角色是？

• Quality != Test , 不要視測試跟開發為兩個獨立流程。測試應該當成開發流程中的一部份。當測試跟開發完美混合區分不時出來的時侯，Quality的目標就達成了。也就是你不能單單只做開發或是測試。而完全不管另一方。

• 當產品掛掉的時侯，第一個苦主會是找誰寫這個開發者。而不是那個沒抓到Bug的測試者。

• Quality is more an act of prevention than it is detection ; Quality is a development issue, not a testing issue.

心得︰大多軟體公司，在找測試人員時，開發能力通常遠不及開發人員。所以常常是自成一國，有自己的Process，跟Schedule，而大體上是用重要的Milesone來跟Developement Prcoess來對齊。所以Testers完全無法融入開發流程的一員。這是團隊人員組成，跟能力配制的問題。如果Developer本身就可以扛下測試的責任時。也許就並不需要那麼多測試人員的。但是這需要Developer本身要有自我的認知，測試的主要責任在自己身上。

• Testing must be an unavoidable aspect of development, and the marriage of development and testing is where quality is achieved

• Tester in Google, are responsible for making other engineers more productive and more quality-minded

• 測試者的主要任務是讓開發者更有效率的去測試他們自己的產物

• 角色1 - Software Engineer (SWE):
• Implement functional code
• Write design document
• Write Test code , 包含 TDD, unit test, 建構與參與大中小的測試

心得: 當公司有花錢找一堆不參與Functional開發的測試人員時，SWE就不可能會花時間寫足夠的測試，因為這些測試是交由測試人員來負責的。所以常常傳統上的共識就變成是 developer 測 unit test，而 tester 測 functional level以上的測試，包含 system testing 跟 integration testing 等等。而 Google 的做法就是讓 Developer 自己來搞，也正好呼應了前面所說的 Scarcity brings clarity。

• 角色2－Software engineer in test (SET):
• Focus on testability and general test infrastructure
• Review designs, codes and risk
• Refactor code to make it more testable
• Write unit testing frameworks and automation.

心得︰工作二年來，直到看到這本書我才了解，內心一直想做的事其實就是書中寫的SET。但是現有的Process並沒有定義這樣的Role，這衝突、矛盾的結果，就讓我感覺我想做的事，跟我做的事，很多都是在做白工。因為團隊沒有共識有SET這個Role。我感受到，團隊陣容跟員工能力如果都是Waterfall的思維構成。那麼不管灌入再潮的Mindset，Methodology，再多Agile的行為，CI的規劃。終究會因為這群人是用Wafterwall運作下的所需能力找來的人。他們只能習慣Waterfall的Process，這是他們最舒服的運作模式。所以，不管換什麼工作模式，終究會被打回原形。成功的 Software Process，或許該從找對人來組成適合該Process的團隊組職開始。那群人就應該會很理所當然的以“舒服”的方法運作下去，一切就會很自然吧。

• 角色3-Test Engineer (TE):
• Put testing on behalf of the user first
• Organize the overall quality practices
• interpret test result
• drive test execution and build end-to-end test automation
• Test Engineer是動態指派到Product Team，跟據需求。

• TE，在Proudct Team，工作約１８個月之後，可以自由地轉去其它的Product Team。對於Product短期而言，似乎是損失，因為少了一個熟悉產品的人。但對於TE有正面影響，可以擁用不同產品的測試經驗 (心得︰對於TE有較長遠規劃)。長遠看來，對於Product，也可以擁有不同產品測試經驗的人才。

• 心得︰

  1. T公司的QA = 20% SWE + 10% SET + 100% TE
  2. T公司的Developer = 70% SWE + 30% SET + 10% TE

比較交集的結果，缺少人專注在SET的任務上。我覺得這就是大部份的Product Automation 弄不起來最主要原因。主要是任務TE的QA們，需要花很多額外的時間，而且使用不同的Codebase (Deverloper 使用 C/C++，QA使用Python)來克服 Testability不好，而需要寫很多跟Product功能相同，但是codebase不同的code。跟一堆 working environment問題。這些問題的正解是SWE跟SET需要擁用相同 Codebase，目標一致，方可有效率地完成任務。而跟本的差界就是在T公司，寫Automation Test主要是QA(其實是TE)的責任。而在Google，這其實主要是Code authors的責任。在Google，專職的Tester，被交附不同的任務，而任務是幫助讓SWE測試更好做，寫出好的Test code，讓SWE可以專注在開發 Feature code 上面。

• Build 的種類，依穩定性區分︰
• Canary Channel : daily builds, build fails is a chaotic sign , for enginners and managers
• Dev Channel : weekly builds, shall passed some set of tests ,for developers day-to-day work
• Test Channel : month builds, passes the most sustained testing, for internal dogfood users(狗食這邊是軟體業的黑話，是指用公司最好用自家產品，像是微軟用outlook，Google用Gmail等等)
• Beta(Release) Channel : stable test channel builds, pass every quality bar the team sets

心得︰以測試的角度，我們應該要測最新的Build，但是一個不穩定的Build，會讓我們的測試工作受阻，稱為testing blocked，所以我們要有能力知道該拿什麼樣的Build，來做目前測試的目的。理論上，照這種邏輯，我們應該隨時可以拿到這五種Channel的Build。

• Crawl, Walk, Run: 先推出 "Minimum useful product" as an initial version，然後再依Feedback來決定下一步要做什麼。其實就是Agile精神。

• 測試的種類，依自動化難度區分，以 small test scope 最小，最容易自動化:

• small test:

  • moftly by SWE, less often by an SET, hardly ever by TEs
  • small 會需要很多 mock , fake, stubs。
  • TEs 有時會執行 small 來幫助 dianose 某個 failure
  • 目的︰是測試一小段code是不是如預期的行為

• medium test: 大部份是自動化，會有多個 features 交互作用

  • nearest neighbor functions : 彼此有關系的 functions，一次只專注部份一組的 functions 上
  • 目的 這個 a set of nearest neighbor functions 彼此交互作用是否如預期？

• large test: usually user scenarios, real user data

  • 測試執行時間比較久，以使用者為出發點的測試
  • 整體功能面的整合測試
  • 檢驗是否實滿足客戶的需求(Validation)

• 三種測試都可能是自動化或是手動，取決的點︰

• 自動化︰不需要人類的才智，直覺，判斷，那麼這些就應該自動化

• 手動 ︰需要人的評斷，像是UI好不好看，Privacy issue, usability test等等，就應該留在手動測試的領域，Google有做很多手動測試，不管是Script或是Exploratory式的。Recoding technology converts manual tests to automated tests。(一般認為Recoding是過時的技術，沒想到Google還是覺得有他的重要性，可以用來減少 regression test

• 把自動化測試的失敗，跟Bug tracking system 結合。比如在之前的測試成功，但是這次測試失敗，自動Fire bug Tracker，留下記錄，把Automation fail直接當成Product Defect，讓Automation bug也視為是Product的Bug。把記錄Email給作者， 知道這次的change是什麼，即早發現 Bug，讓苦主可以盡快休復。