敏捷測試究竟是靈丹妙藥仍是又一個忽悠

最近讀了不少網上關於敏捷的辯論，我想起一個故事：

話說清朝的時候慈禧太后據說西方國家有個新的交通工具，汽車，它坐在舒服跑的很快。因而就叫人買了一輛回來。可是用的時候沒有人會開，因而不得不把 汽車用幾根柱子綁起來作成了轎子，讓幾我的擡着。由於汽車太沉，幾個轎伕步履蹣跚，走不了幾步就得歇歇。結果之前半個時辰的路走了好幾個時辰。並且到了後 由於門很窄，汽車作的轎子過不去，她也不得不老遠就下來本身走一段。慈禧太后很不高興就得出結論：

一、汽車前期投入大，維護成本高。

二、沒有轎子走的快。

三、不少地方汽車都不適用。

四、汽車是個大忽悠的東西，根本無論用。

那麼咱們如今對敏捷的認識是否是和慈禧對汽車的認識相似呢？是由於咱們不會用敏捷呢，仍是由於敏捷就是個忽悠？

在國外一般一個概念出來以前已經有不少年的實踐積累，而後爲了你們交流方便或者提升普及度給其一個名字。因此是先有實踐，再有概念。可是在國內正好 相反，咱們先把國外「先進「的概念引進來了而把產生概念的多年實踐忽略掉了。可是概念又太虛不能當飯吃，最終仍是須要具體東西和具體作法。因此不得不根據 概念來設計出各類各樣的作法來。這些作法聽起來不錯，很是符合概念，可是在項目中一使用就不靈了，舊的問題沒有解決，新的問題一大堆。最終得出汽車是個大 忽悠的結論。

敏捷和雲計算是兩個很是典型的例子。不少人爲了敏捷，文檔不要了，計劃不要了，測試用例也不要了，認爲幾我的站在走廊裏溝通溝通就把一切都搞定了， 由於敏捷了嘛。可是問題並無由於「敏捷「了而被解決掉，因而乎得出敏捷是個忽悠的結論。雲計算也同樣，不少人認爲雲計算就是數據中心，因此你們大興土木 創建數據中心。可是建完數據中心之後呢？沒啥用處呀。那你們都在吹捧雲計算，不就是個大忽悠嗎。 卻不知，人家是由於業務須要不少年了已有數據中心，爲了提升數據中心的使用率，開始對公衆開放資源，因此纔有了雲計算。

先有概念再造實踐的作法違背了事物發展規律，不只解決不了現有問題，並且帶來新的問題。敏捷是個好東西，在特定狀況下。咱們須要搞明白的是它要解決 什麼問題的？它是如何解決的。而不要在意它叫什麼名字或則防止生搬硬套。還有越是先進的東西對人和基礎設施的要求越高。好比飛機再好，沒有飛行員或則沒有 機場也沒有用。高鐵跑的越快對鐵道的要求越高。

軟件測試也是同樣，作質量控制不是爲了趕時髦。若是你的項目只作3個月就完全結束了，並且就3－5我的，不會有人離開也不會有人進來，也不須要和其它任何項目打交道，或則你的產品在早期實驗階段，你能夠不要文檔，不要計劃，不要記錄bug，徹底靠口頭交流。不然的話：

一、不能沒有文檔:  可是要減小沒必要要的文檔，避免過於詳細的文檔，使用易於更新和維護的動態文檔。

一、不能沒有計劃: 距離如今越遠計劃越模糊，可是距離如今越近計劃越詳細。

一、不能沒有紀律:

與其在琢磨如何敏捷測試，不如一步一步把自動化作好，把持續集成作起來，建立更多的測試工具以提升測試效率，把質量反饋系統作起來，把dev提交代碼前的質量檢查作起來，把在產品中測試作起來， 把測試工程師的素質提升上去，。。。。

等到這些都創建起來了後，你發現本身其實已經很敏捷了。

來源：Bill LIu