謬論：找到并修正所有的缺陷將會建立一個高質量的產品。
事實：近來的研究顯示，只有10%軟件開發活動，例如建立客戶需求特性，能夠實際增加客戶的價值。開發過程中加入一定比例的特性能夠增加產品在市場中的競爭力，但是它們往往不是客戶要求或者期望的。查找和修正這些缺陷不會增加客戶的價值，因為客戶可能永遠也不會遇到這類的錯誤。
從另一個角度講，迭代測試實際上會減少缺陷的數量和客戶等待的時間，當然這是基于客戶價值考慮的。在迭代過程中引入客戶意見，迭代測試壓縮對客戶的交付周期，從而最大化應用程序對于這個客戶的價值。
謬論：不斷的回歸測試每一件我們更改的代碼是十分冗余和費時的工作，只有在理想化的世界中才會這么做。
事實：回歸測試并不意味著“每次測試每件事”。
迭代回歸測試的意思是測試每個階段中敏感的部分。它也意味著基于改動效果，產品歷史和早期測試結果而更改我們的測試覆蓋率。
如果你的回歸測試是自動執行的，那么你可以在同時運行所有測試。如果不是，那么請選擇你想要完成測試的部分進行測試。例如，你可以在“驗收”產品之前之前運行一個“完整的回歸套件”或者“一系列驗收測試”f。由于每一個回歸過程都不是必須相同的，測試不需要每一次都相同。把精力集中在特性和測試上面對于即將到來的交付階段是十分有意義的。例如，如果你使用第三方的組件，比如一個承包商或者開源的產品，完整的回歸套件將會把焦點集中在外部和內部組件的集合點上。如果在你初始化第三方模塊完整回歸測試時，發現了缺陷或者回歸，那么你可以選擇添加基于早期結果的額外測試來改變你的回歸套件。
換句話說，如果你在你的控制之下在整個產品開發中進行一系列的缺陷修復工作，那么完整的回歸套件應該被完全聚焦并構建在你的端到端，高概括的客戶用例上。如果更改被限制在一個領域，并且產品擁有一個穩定的質量追蹤記錄，那么你可以把精力全部集中在這個回歸套件中。同樣，在最后階段，你或許需要一個非常小的能夠覆蓋介質安裝的完整回歸套件，但并不是深層次的或者端到端的測試。完整或者驗收回歸套件的重點依賴于在前一個周期測試了什么，產品的一般穩定性和下一個迭代的重點。
謬論：這不是一個缺陷——特性隨著設計而出現。
事實：過多的解釋為什么產品會做它現在正在做的事情是一個普遍的陷阱。有時候我們知道的太多了。當缺陷被修復和評審的時候，我們經常為缺陷自圓其說。有時候我們把缺陷標志成為“伴隨設計更正”或者“不計劃修復”，因為應用程序實際上是伴隨著設計工作的，更改設計將是過于昂貴和具有風險的。同樣的，我們解釋了很多關于“它是一個外部組件”或者“它是一個鐘表或者汽笛”的可用性。我們的窗口小部件或者 UI 控件將會受到限制�；蛘呶覀兏嬖V我們自己“一旦用戶知道要這么做，他們將會很好”。
總而言之：我們了解了代碼的輸入和輸出，以及他們為什么這么工作。在這個部件層次上，我們做了非常合理和明智的決定。但是我們缺少對整個客戶經驗的整體觀。我們沒有給我們編碼平衡和工作區帶來最終效果增值。我們的主要聚焦點是使重要的代碼按時完成。通過聚焦于個別的特性或者組件，我們不經意的做了一些代碼的決定，這對產品的全面流程和可用性產生了消極的影響。畢竟，最大限度影響客戶效率的是可用性。而驅使用戶放棄一定數量功能的也是可用性。
超過上面的細節層次提升我們對于項目的見解，會允許我們以客戶期待的視角看待我們的產品——通過全局的層面，而不是單個的組件。這種提高后的視角幫助我們忽略了對于產品為什么這么工作的所有原因的探究�？蛻舨粫P心給定的設計是否會加快代碼的設計。對于客戶來說用戶界面是否與你特定開發任務外的組件X的API沖突與他們無關。他們只關心這個產品在他們完成自己的目標時是否會協助或者阻礙他們的工作。
謬論：一個測試人員的唯一任務就是找到程序缺陷。
事實：關于測試人員的作用的這個觀點是非常有局限性的，并且對于客戶沒有增加價值。測試人員都是被測試系統，應用軟件或產品的專家。不象負責一個特殊功能或組件的開發人員，測試人員懂得系統作為一個整體是如何工作的來達到客戶的目標。測試人員懂得由產品增加的價值，關于產品效率的環境的影響，以及從產品得到最多輸出的最好方法。
通過這個產品知識擴展了我們測試人員的價值和作用。擴展測試人員的作用（諸如技巧，技術，指導方針，以及為使用而進行的最佳練習）最終減少了客戶所有權的成本和增加了測試人員的商業價值。 謬論：我們沒有足夠的資源和時間來全面測試產品。
事實：你不需要全面測試產品——你需要充分測試產品來減少一個客戶將被消極地影響的風險。
變化市場的事實通常要求在給定的時間框架中詳盡地測試一個產品，但事實上是不可能的。這就是我們需要測試的一個實用方法的原因。關注于你的客戶的商業過程來確定你的測試優先級。聯合系統的內部客戶來測試你的產品。當提供真實世界可用性的反饋時，這些步驟增加了你的測試資源。同時你也可以在一個外部客戶實驗室中來做你的系統測試，來增長你的真實世界環境的經驗而不用增加你的維護或系統管理活動。
謬論：測試應當發生在一個被控制的環境中。
事實：測試環境越象最終產品環境，測試越可靠。如果客戶環境被嚴格控制，那么你可以在一個被控制的環境中做你所有的測試。但是如果最終產品環境沒有被控制，那么你在一個被控制的環境中做你測試的100%的工作將會使你錯過一些重要的情況。
盡管難以預測的事件和不同的環境難以效仿，但它們是十分常見的，因此也是值得期待的。在我們當前的全球市場能夠中，你的應用軟件將被用于靈活的，分布的，和多變的情況是十分可能的。在迭代測試中，我們因此根據處于不同環境中的客戶來同時確定商業使用模型檢查和系統測試活動的時間進度。早期的商業使用檢查確定目標客戶市場的差異性，優先于編碼。在客戶現場進行系統測試是在真實世界中運用了我們的產品。盡管產品的這些“預發布”版本仍然在我們開發人員的手中，并運行于我們的工作站上，但它們已經在客戶真實世界的辦公室（或實驗室）的環境和應用軟件中被測試。盡管這個策略不能覆蓋每一個可能性，但它承認不可預知性的存在。
謬論：所有的客戶有著同等的重要性。
事實：一些客戶要比其他客戶更加重要，這是基于一個特殊發布的目標。例如，如果一月發布的發布定義特性是將傳統MyWidget數據轉變為MyPalmPilot的特性，那么我們的用戶使用MyWidget和MyPalmPilot的反應對于這個特殊的發布來說，要比其他客戶的輸入更加重要。
所有我們的客戶當然都是重要的。但是迭代測試的目標是關注于這個特殊迭代法的最重要特性。如果我們正在將特性XYZ輸送到這個迭代法中，我們需要來自于熟悉優先的XYZ功能的使用者的專家對XYZ的評價。就象我們歡迎其它反饋一樣，諸如新使用者的印象，XYZ特性的優先考慮。在開發的這個階段，剛剛接觸市場的使用者不能幫助我們設計“正確的XYZ特性”。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
