在我作為質量保證經理的時候，我從大量的軟件開發實踐中獲得了經驗，這種經驗包括迭代開發和稱作“瀑布式”的方法。前者模型通常會被認為比后者的方法更加現代。但是這往往是一個荒謬的想法：兩種方法都是產生于60年代。另外一個荒謬的想法是認為瀑布方法盛行于70年代。被譽為瀑布方法之父的Winston Royce認為這實際上是一種誤解。他建議單向的瀑布方法只是為了維護項目而存在的。Royce建議在第一次開發軟件應用程序的時候一個迭代要“執行兩次”。
從這種誤解開始，軟件開發領域產生了很多荒謬的言論。這篇文章將會質疑和揭穿一些廣泛流傳的關于迭代開發和迭代測試通常的一些荒謬的言論。包括迭代開發原則是如何解決這些通常的誤解的，并會把你帶到測試方法的真正道路上，這種方法將會減輕和避免很多軟件開發過程中的缺陷，其中有很多是被我們堅信的“謬論”。
謬論：在多數的軟件開發項目中，我們帶著拋棄這個代碼的想法，很快的編寫一個原型應用程序，用來降低風險和證明概念的正確性。
事實：這個方法沒有任何問題。但是，由于時間的壓力或者是結果的獎勵，我們并沒有拋棄這個代碼。事實就是：我們的原型實際上就是早期代碼。那個代碼就成為了我們新的應用程序的基礎和框架。然而，由于它是在假設會被拋棄的情況下建立的，它會迂回于需求評審，設計評審，代碼評審和單元測試之間。我們下一代的應用程序是建立在不確定的基礎之上的。
在迭代開發周期中，持續的驗證是一個好的方法，在每一個迭代開發早期的原型是被鼓勵的。但是任何的代碼在提交到產品前，都需要遵照最佳實踐，來保證它的穩定性和可維護性。一種鼓勵在項目最開始做正確軟件開發實踐的方法是使用初始代碼來計劃，檢驗和呈現你打算在軟件開發階段全程使用的過程。作為迭代測試方法的一部分，你可以使用早期代碼周期來測試你產品的概念，同時可以清除開發過程中的小故障。
謬論：在開發周期中過早的開始測試活動會增加產品交付的時間，降低產品的特性。
事實：測試在開發周期中不是耗時的活動。診斷并修正錯誤才是耗時的工作，是開發過程中的瓶頸。
測試不是導致我們產品擱淺的障礙——相反它是避免我們撞上巖石的燈塔。無論我們是否尋找錯誤，它都存在于產品中。迭代測試會幫助你接近它們產生的地點。迭代測試最小化了糾正錯誤的花費。
謬論：如果你沒有完成的產品那么你就不能做測試。
事實：迭代測試并不被限制必須測試代碼。
你的小組生產出來的每一個產品都可以根據可交付性的成功標準進行驗證。同樣的，你用來生產可交付使用產品的每一個過程或者程序都可以用你的成功的質量標準來確認。這包括產品概念，體系架構，開發框架，設計，方法和你遵循的開發程序。
你可以從這個局部列表中看到，多數的條目沒有包括代碼。因此，當你在等待有可交付使用代碼時，你已經錯過了維護質量和降低風險的機會。我不同意這個廣泛接受的觀念：“你不能對產品進行質量測試”。你可以這么做，只要你開始的足夠早。
謬論：如果在每一個開發部分都有一名開發人員（或者一個單獨的資源），那么你的工作將會更加有效率。在這個簡單的論點中，如果你擁有30名開發人員，那么2人一隊進行開發，你可以同時開發15個部分。如果你只給一個部分分配一名開發人員，那么你可以同時開發30個部分。這樣會使你的產品完成度更高。
事實：一個部分只用一名開發人員完成有很大的風險：沒有第二個人可以維護和理解這個部分的內容。這個策略產生了瓶頸和延遲。缺點，增加的需求或者修改會全部壓在這個開發人員身上。為了按時完成工作，你的開發人員不得不為延長的產品周期而付出在周末加班的代價，因為他是這個部分唯一可以繼續新特性開發和修正錯誤的人員�，F在你的整個項目時間表都由這個英雄般的“單個開發人員” 1 負責。一旦這個人離開了小組，去度假或者出現一些不可控的情況，那么你的時間表將延期。由于你選擇了這種執行和管理的開發策略，你現在不能對你的小組作出調整。
成對的開發，測試，代碼評審和設計評審聽起來更加有實際效果，它不但能增加產品的質量，還可以訓練其他部分的人員，它能夠增加你資源共享和維護項目代碼的能力。一隊中的兩個人員不必要都是這個領域的專家。他們只要擁有可以消除先前討論過的瓶頸問題的能力就可以了。
此外，把開發小組分成合理的更小的獨立小組，能夠使得擁有不同技術能力的開發人員在不同的方面更加有效的工作。一個小組分配多個人員，就可以避免把不同的任務分配給一個特定的開發人員。當你擁有多個資源可以分配的時侯，把一個任務分配給單個的開發人員會產生錯誤的依靠性。類似于銀行的多個出納員服務一條等待的客戶隊伍，當開發人員完成一個任務準備進入下一個任務的時候他們的效率會有所改進。
謬論：編寫代碼是開發人員的主要任務。
事實：在開發小組中每個人員的主要任務是生產符合客戶需要的產品。這就意味著當你做需求評審活動時，開發人員的主要工作就是“需求的評審”。當你做設計活動時，開發人員的主要任務就是建立和評審設計文檔。當你做代碼活動時，開發人員的主要任務就是產生沒有漏洞并且滿足客戶需求的代碼。當你做文檔評審活動時，開發人員的主要任務就是確保用戶的輔助原料和錯誤信息能夠使得客戶的知識曲線變得平緩。當你做安裝和設置工作的時候，開發人員的主要工作就是確�？蛻艨梢院茌p松的設定和配置你的產品，這樣他們就可以盡可能高效的完成他們“真正的”工作。越是需要更大的努力來使用軟件完成任務，客戶的投資回報率就會越低，應用程序失敗的機率就會越高。
謬論：軟件開發和測試的需求需要很穩定并且盡早的定義好，這樣才最有效率。
事實：如果我們最終的目標是“有效率的軟件開發和測試”，那么穩定和定義良好的需求在最開始是必須的。但是我們實際的目標是生產一個客戶承認的產品。我們大部分人都承認我們往往不知道什么才滿足客戶需求的。因為在現今的市場情況下，需求是經常變化的，例如新的產品和選擇，我們經常要在被介紹新概念和信息之后改變我們的主意。如果你承認上面的情況，那么一個主要的原因就是為什么我們不能有效地保證需求的穩定性。在開發過程中頻繁的和產品交互會不斷暴露客戶的需求，使得我們變更我們的過程來更好的達到客戶的變化需求和價值。 謬論：當代碼設計的時間超過了時間表的計劃，降低測試的時間可以幫助我們重新回到時間表的計劃上。
事實：一般情況代碼設計的延誤是由于未預料到的困難或者沒有按照最開始的設計工作。當我們發現我們低估了項目的復雜性的時候，縮短測試時間是一個糟糕的決定。相反，我們應該保證測試的執行，因為測試的結果是建立在我們低估代碼設計的情況上的，測試的效果或許也會被低估。因此我們需要定制更多的測試時間來更正開始的判斷，而不是減少測試時間。
迭代測試增加了測試時間但是并沒有延誤整個的時間進度，因為在每一個迭代過程中測試過程都是提前開始的。同樣，產品的質量決定了需要測試的數量——而不是由時間決定的。例如，如果產品是可靠的，在很多領域都沒有發現缺陷，并且測試進行的十分順利，那么你可以在保證測試數量和測試覆蓋率的前提下降低測試的時間。如果產品不夠穩定，發現了很多缺陷，那么你需要增加測試的周期直到達到質量標準。請記住，測試并不是項目最耗時的工作。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
