Marick認為一個模型不應該規定那些和當前所公認的實踐不一致的行為。我也很認同這一點。X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終合成為可執行的程序。(右上半部分），這些可執行程序還需要進行測試。已通過集成測試的成品可以進行封版并提交給用戶，也可以作為更大規模和范圍內集成的一部分。多根并行的曲線表示變更可以在各個部分發生。
由上圖中可見，X模型還定位了探索性測試（右下方）。這是不進行事先計劃的特殊類型的測試，諸如“我這么測一下結果會怎么樣？”，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟件錯誤。Marick雖然沒有對此進行明確的說明，但一定很樂意看到該方法的界定。
然而，關注于這樣的低級別的行為可能會引起不同的議論。一個模型和一個單獨的項目計劃有所不同。模型不應該描述每個項目的具體細節，模型應該對項目進行指導和支持。當然，代碼的交接也可以簡單地認為是一種集成的形式。而V模型也并沒有限制各種創建周期的發生次數。
Marick和Graham都一致認同，應該在執行測試之前進行測試設計。Marick建議：“在你掌握相關知識時進行設計，在你手頭有交付內容時進行測試�！盭模型包含了測試設計的步驟，就象使用不同的測試工具所要包含的步驟一樣，而V模型沒有這么做。但是，Marick的例子提示，X模型在這層意義上看也并不是一個真的模型，取而代之的是，應該允許在任何時候選擇使用測試設計步驟。
事先計劃
Marick對V模型提出質疑，也因為V模型基于一套必須按照一定順序嚴格排列的開發步驟，而這很可能并沒有反映實際的實踐過程。
盡管很多項目缺乏足夠的需求，V模型還是從需求處理開始。V模型提示我們要對各開發階段中已經得到的內容進行測試，但它沒有規定我們要取得多少內容。如果沒有任何的需求資料，開發人員知道他們要做什么嗎？我主張在X模型和其它模型中都需要足夠的需求并至少進行一次發布。雖然在沒有模型的情況下也必須正常工作，但一個有效的模型，可以鼓勵很多好的實踐方法的采用。因此，V模型的一個強項是它明確的需求角色的確認，而X模型沒有這么做，這大概是X模型的一個不足之處。
Marick也質疑了單元測試和集成測試的區別，因為在某些場合人們可能會跳過單元測試而熱衷于直接進行集成測試。Marick擔心人們盲目地跟隨“學院派的V模型”，按照模型所指導的步驟進行工作，而實際上某些做法并不切合實用。我已經盡自己的努力把Marick的關于需要很多具有可伸縮性的行為的期望結合進了X模型，這樣，X模型并不要求在進行作為創建可執行程序（圖中右上方）的一個組成部分的集成測試之前，對每一個程序片段都進行單元測試（圖中左側的行為）。但X模型沒能提供是否要跳過單元測試的判斷準則。
在“階段”之外
一個模型的主要目標應該是描述如何把某件事情做好。當一個模型所規定的基本要求還不完整的時候，模型可以幫助我們認識到這些不足，這也是其價值所在。雖然我們承認，在沒有足夠多的需求的前提下，系統開發還可以繼續下去，X模型可能會提倡付出額外的努力來進行更多的實踐行為。同樣的，也可以因為喜歡集成測試而選擇跳過單元測試，但其價值可能有一些虛幻的成分在，因為一般來說，在單元測試中發現問題進行解決的代價較小，而在集成測試中發現問題所付出的代價要大得多。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
