研發測試的6層次
大概 6 年前曾和同事分享過測試的幾個層次，今天的理解又有些許不同。試圖用“三字經”體，描述如下。
層次 1 － 無測試
沒有專職的測試人員。如果你在小企業，在初創企業，或者足夠老，你就會經歷過。
層次 2 － 有測試，無用例
領導實在覺得產品質量對實施和使用有了影響，又或者不知道怎么做，或者沒有太多的銀子可以投入，又或者覺得既需要測試又覺測試也解決不了大問題，于是就找壹兩個做事認真做事的畢業生，聽話切成本不高，當然也別指望畢業生聽過測試用例等術語了
層次 3 － 有用例，無設計
這個層次在生長在本土企業，也生長在外企，它存在典型土壤就是瀑布式開發＋開發和測試團隊分離管理。設計本是瀑布式開發的軸心，和開發團隊與測 試團隊的紐帶。但由于（開發人員們）眾所周知的原因，實在沒時間花在設計文檔上，趕進度時也實在沒心情更新設計文檔，更何況相對年輕的開發人員難有全面而 深入的設計，老板又認為這個技術又有什么難，即沒必要請高大上人士加盟，又沒必要做高端外包，永遠經濟的奢侈品才是老板的最愛。
層次 4 － 有設計，無敏捷
這個是目前業界最長見的情景劇。在互聯網時代，不對應該已經是云時代了，瀑布式的開發遠遠趕不上需求的變化和盡快發布的渴望，于是在瀑布式的開 發過程中，被分成了多個階段，每個階段完成幾個新特性。設計文檔于是也分階段唯特性而生。萬幸中的不幸是，云時代的天總是陰晴不定，變化莫測。好好的設計 像女人的臉總是變來變去（是因為彩妝？是因為整容？）。
開發人員勉強支撐者，產品的質量已經無暇考慮，但凡能夠寫出或修改完代碼就已經是阿彌陀佛。苦不堪言的測試人員在人員有限和越來越多有變化莫測的特性中焦頭爛額，最后不得不制定一套在覆蓋率和質量間平衡的測試理念，并說服老板們認同。
老板畢竟是老板，拋出自動化的概念，把球有傳回了后衛們，后衛于是頭碩大，他知道的是只有中后衛可以耍自動化這樣的花活，他不知道的是中場是為 進球服務的，誰會給后衛提供便利呢？！于是測試團隊在進球是死罪，不完成自動化是活罪，開發人員又忙于特性和變化，開發支撐測試是無稽之談的狀態下，輾轉 騰挪，頗有些馬戲團的猴戲的架勢。
層次 5 － 有敏捷，無設計
終于敏捷開發替代了瀑布式開發，敏捷已經如 Transformer（電影變形金剛），深入人心。sprint 的周期已經從一個月降到了 2 周甚至 1 周。測試自動化也突飛猛進，達到了五成，八層，甚至 90%。研發和測試的溝通也親密無間。在研發，測試，老板，產品經理看來，一切都很美。
然而在繁花簇錦氛圍中，設計文檔已悄悄的隱退了。一旦產品研發從A地遷移到B地，部分裁員，多產品架構重組，諸如此類，開發人員心里又恨又氣， 把前任的親戚和祖宗八代都在心中默數千百遍。測試人員看著海量的自動化代碼，卻顯有一例和測試用例相符，于是滄海一聲笑，跳進了大海。
怪誰呢？敏捷的提出者從未在理論中涉及設計文檔（搜索并參見 Agile Scrum），讀懂了敏捷的 Scrum Master 也未曾從老板哪里領到設計文檔，測試用例的 KPI，快速＋變化＋自動化覆蓋率＝敏捷目標。
怪誰呢？從沒有哪本 Agile 的專著說“不”需要設計文檔。佛法云：盡在其中。和尚說：不盡其然。是和尚讀歪了經文，還是經文交錯了和尚。看你的了。
層次 6 － 無測試
即 4 和 5 這對矛盾之后，6 與 1 也是一對。這就是對比和遞歸的組合。
隨著迭代的速度越來越快，傳統的手工測試已經在 5 和 6 中徹底淪為了外包工作，留下的精英也主要在跨產品（特別是和第三方）的 solution 高端測試上。傳統的自動化開發人員，但凡除寫代碼外，對產品特性無體會，代碼堆砌不精煉，或者測試用例設計無思路的，都不得不跳槽去了4，5 的企業。
在這里，開發人員和測試人員再次融合為一個角色。簡練的設計，靈活的架構，多層次抽象，接口即是產品的一部分又是自動化測試的一部分，不斷的原 型，不斷的重構，核心設計文檔快速的修訂并輔以音視頻，自動化代碼不過是產品中與設計文檔，產品源碼，產品執行代碼并列的有一個目錄而已。每一次發布后都 會整理設計文檔，對架構反思，對邏輯層次做再一次的優化，并把這些變化回歸到設計文檔本事。
抱歉的是我沒有經歷過層次 6 的產品開發，僅僅是從我 2 個人的小項目經歷的推論。顯然這樣的研發各個是鐵人 5 項選手，至少是 3 項的高手。精英團隊的單人成本確實很大（如我：），溝通成本降低了超多，總人數大量的減少總體成本依然可以降低，而質量顯著提高。其風險是某個人的長時間 病休或離職，會對產品有一定影響，可以使用一些彌補機制或預防機制。
親，你的項目，產品，公司在哪層呢？
MK@我的閣樓 July 6，2014
<span id="shareA4" class="fl">
</span>