閱讀本文大概需要 4 分鐘。
前面我已經寫了三篇關于《Google 軟體測試之道》的薦讀和讀書筆記，這是我讀完一本書之後寫讀書筆記最多的一次了，主要是因為他引發了我太多的思考，也開拓了我對于測試未來的想象。
前三篇可以點選連結檢視：
Google 軟體測試之道
Google 軟體測試之角色職責
Google 軟體測試的未來
今天是這個系列的第四篇，仍然是關于書中第五章的内容解讀。
第五章中 James 除了闡述 Google 軟體測試的未來之外，還着重提到了 Google 流程中的緻命缺陷，裡面有一些和我們目前的情況十分相似，另一些則警示我們要提前注意可能出現的問題。
下面我會針對這些缺陷，逐個進行說明。
缺陷一：測試成了開發的拐杖。
本來品質是所有人的事，但是因為有了測試部門的存在，開發人員越來越少的考慮品質問題，越來越不會去測試，因為他們認為品質是測試人員的責任。
關于這點，應該是有共識的，有回報找測試，漏出 bug 找測試，所有問題都可以歸結為一個終極問題「為啥測試沒有測出來？」
如果繼續目前的做法，這個問題是沒法得到解決的，但是可以借助之前「測試即服務」的方法間接解決。
我們服務于産品，在需求階段解決需求問題。
我們服務于開發，在編碼階段解決架構和技術實作的問題。
我們服務于使用者，從使用者角度解決體驗性問題。
我們服務于品質，深層次挖掘邏輯問題。
缺陷二：開發和測試的隔離，阻礙了測試人員對産品的關注。
James 要表達的是 Google 獨立的測試部門，導緻他們更注重測試工作本身的事情，進而忽略了我們是為業務服務的大目标。
這個在國内目前的環境，基本不是問題，甚至部分公司會出現測試過于依賴業務，進而失去了自己作為測試應該具有的獨特視角，僅僅成為一個工具。
我了解隻要記住兩點就夠了：
測試是為保障品質服務的；
品質保證是為業務目标服務的；
缺陷三：測試人員往往過于崇拜測試産物。
這點主要強調的還是測試太過于關注測試本身，比如測試流程、計劃、用例、工具、系統、bug 等等，所有這些都是測試過程的産物，所有這些産出的目标都應該是為了保證産品品質。
這其實牽涉到另一個比較大的話題「如何進行軟體測試人員的績效考核」，考核目标不一樣，對應的就是大家的關注點的不一樣，是以這個方面每個公司根據自己現狀不同，都是有一些差異。
總體來說，James 表達的這個意思是沒問題的，确實業務是最終的目标，測試人員應該把産品放在第一位，目前剩下的就是怎麼去制定合理的考核名額，讓我們的目标和業務目标能夠保持一緻。
缺陷四：産品經過測試後并仍然會遺漏問題。
這點确實沒法完全保證，James 指出的原因是 TE 隻是想象自己是使用者，而試用者是真實的使用者，是以才會漏出問題。
從我的經驗看，其實可以分為兩種情況考慮。
一種是功能問題的漏出，比如邏輯分支缺少用例覆寫。
這種肯定就是測試人員的問題了，有可能是需求沒有搞透徹，有可能是實作邏輯沒有弄清楚，有可能是自己用例設計的方法不熟練，解決辦法當然是對症下藥。
另一種是使用者場景的遺漏，比如真實使用者使用産品的操作方式沒有覆寫到。
這種情況，産品、開發、測試和營運部門都是應該參與試用的，特别是作為産品的第一批使用者，我們應該在我們的生活場景中去使用我們的産品，而不僅僅是想象我們的角色，一定要作為真正的真實使用者去使用産品。
當然，内部試用、灰階釋出和快速疊代也可以解決這個問題，但是這時候漏出的問題應該是符合預期的，因為本來就是期望他們來發現這些體驗性問題。
以上，James 提到的 Google 流程中的缺陷在你目前流程中是否存在同樣的問題？目前是怎麼解決的？是否有更好的解決方案？歡迎留言說出你的想法。