在上圖右邊的方塊中，最好要改成為“執行某些適當的測試并得到相應的結果”。

　　圖中的左邊會怎樣?考慮一下系統測試設計，它的主要根據和信息來源是是規格說明。假設你知道有2個單元處在一個特定的子系統中，它們在運行時相互聯系，并且要執行規格說明中的一個特定的聲明。為什么不在該子系統被集成時立即對此規格說明中的聲明進行測試，就象是在設計完成后立即開始測試的設計一樣呢?如果該聲明的執行和子系統外的子系統沒有任何關系，為什么還要等到整個系統完成以后再測試呢?難道越早發現bug成本越低不對嗎?

　　在上一張圖片中，我們用了向上指的箭頭(更有效，但在時間上有延遲)。這里還可以把箭頭往下指(在時間上提前)：

　 新的方法：在不同階段上提前進行測試設計

　　在這種情況下，左邊的方塊中最好被標記為：“在當前信息條件和情況下可以做的任何測試設計”。這樣，當測試設計得自于系統中某一個組件的描述時，模型必須允許這樣的測試在組件被裝配之前被執行。我必須承認我的圖片非常難看，這些箭頭指得到處都是，對此我有2點說明：

　　1. 我們所討論的事情不是創造美，而是想要發現盡可能多的嚴重錯誤，同時盡可能地降低成本。

　　2. 難看的部分原因也是因為必須按照某些次序來執行的結果，亦即開發人員先提供系統描述文檔，然后測試和這些文檔進行關聯。這些文檔就象是堅實的老橡樹，而測試設計則象是細細的枝條纏繞在樹上。如果我們采用不同的原理來進行組織，圖片可能就會變得好看些。但復雜性仍不可避免，因為我們要討論的問題本身就很復雜。

　　V模型失敗的原因是它把系統開發過程劃分為具有固定邊界的不同階段，這使得人們很難跨過這些邊界來采集測試所需要的信息。有些測試應該執行得更早些，有些測試則需要延后進行。而且，它也阻礙了你從系統描述的不同階段中取得信息進行綜合。例如，某些組織有時執行這樣的做法，即對完成的工作進行簽署。這樣的規定也擴展到系統測試的設計。簽署表示已經過評估，該測試設計工作已經完成，除非對應的設計文檔改變，否則就不會被修訂。如果同這些測試相關的信息后來被重新挖掘和認識，例如，架構設計表明有些測試是多余的，或者，詳細設計表明有一個內部的邊界可以和已存在的系統測試組合在一起進行測試的話，那么實際上還需要繼續調整原來的系統測試設計。

　　因此，模型必須允許利用不同來源的綜合信息進行個別的測試設計。另外，模型還應該允許在新的信息來源出現后重新進行測試的設計。