可以用同行評審來完成，沒有一個是基于代碼的。而且上邊的例子中沒有一個評價是窮盡的，必要時我們可以進行的其他評價。關(guān)鍵是我們輸出一個交付產(chǎn)品（如需求文檔），在我們能夠正式稱它是完備的并可被下一開發(fā)步驟使用之前，我們必須基于預(yù)期的特征對之進行評價。而進行這些評價需要比進行同行評審更加復(fù)雜的技術(shù)。
這就是評價和測試的關(guān)鍵所在。一個特征的預(yù)定義集合，盡可能被明確定義，用來對一個交付產(chǎn)品來進行確認(rèn)。例如，當(dāng)你在學(xué)校，進行了數(shù)學(xué)測驗，老師會拿你的回答與預(yù)期答案相對比。老師不會僅僅說他們看上去也是合理的，或者他們更加準(zhǔn)確。答案是9.87652，要么它對，要么不對。同時，老師也不會等到學(xué)期結(jié)束才將在課程早期交上來的進行判卷，在他們做出來之際就得到了測試。目前我們軟件開發(fā)承擔(dān)更加大風(fēng)險，難道我們還可以有任何的不嚴(yán)格和不及時嗎？
這些應(yīng)當(dāng)進行評價和測試的交付產(chǎn)品應(yīng)當(dāng)包括需求規(guī)格說明書，設(shè)計規(guī)格說明書、數(shù)據(jù)轉(zhuǎn)換規(guī)格和數(shù)據(jù)轉(zhuǎn)換代碼、數(shù)據(jù)庫設(shè)計說明書、培訓(xùn)資料、硬件/軟件安裝規(guī)格、用戶手冊和應(yīng)用程序代碼等等。當(dāng)然這并不是一個完整的列表。問題的關(guān)鍵是，在你的項目生命周期中的每一個交付產(chǎn)品都必須被測試。
對于一個給定交付產(chǎn)品的評價和測試可能會延續(xù)項目生命周期的多個階段。越來越多的軟件組織開始從瀑布式模型向迭代式模型轉(zhuǎn)變。例如，設(shè)計規(guī)格可能會經(jīng)過三個迭代才能產(chǎn)生。第一個迭代定義體系結(jié)構(gòu)—它是人工的還是自動的，是集中的還是分散的，是在線的還是批命令式的，是直接文件存儲還是通過關(guān)系性數(shù)據(jù)庫等等。第二個迭代則可能繼續(xù)推動設(shè)計，來鑒別所有的模塊和模塊間的數(shù)據(jù)交換機制。第三個迭代則定義模塊內(nèi)部的偽代碼。每個迭代都應(yīng)當(dāng)基于適當(dāng)?shù)奶匦詠磉M行評價與測試。
評價和測試的類型必須是魯棒的、堅固的。這包括對功能、性能、可靠性-可用性/實用性-可服務(wù)性、易用性、可移植性、可維護性和可擴展性等的驗證，但絕不僅限于此。
總之，每個階段的每個交付產(chǎn)品必須通過正式的、訓(xùn)練有素的技術(shù)來對適當(dāng)?shù)膶傩赃M行評價和測試。
二、在CMM中為什么要加入這個獨立的KPA
由五個重要方面能說明必須有一個獨立的軟件評價與測試的KPA，即：
(1)評價和測試在促進向有紀(jì)律的軟件工程過程過程的文化轉(zhuǎn)變中的作用；
(2)評價和測試在項目跟蹤中所起的作用；
(3)整個開發(fā)和維護在評價和測試部分的預(yù)算；
(4)評價和測試訓(xùn)練對軟件交付時間和成本方面的影響；
(5)評價和測試對軟件殘余缺陷的影響。
將軟件工業(yè)從一種手工(藝)匠方法向真正的訓(xùn)練有素的工程層次邁進實在是一種文化的轉(zhuǎn)折、躍變。CMM的首要的而且也是最重要的目標(biāo)是，建立一種機制來推進向軟件工程的文化改變。但是一個文化不可能發(fā)生激烈的改變，除非你深刻理解改變的重要性。必須全面理解向新的文化改變所能給我們解決的問題。最后這一點，將使我們引導(dǎo)我們來討論測試在這一加速向訓(xùn)練有素的文化改變中所起的作用。
在1960年代后期，IBM是第一批開始應(yīng)用正式軟件工程技術(shù)的組織之一。一開始使用的是Dijkstra支持的技術(shù)。具有諷刺意味的是，并不是由軟件開發(fā)人員發(fā)起這項努力的，而是軟件測試人員。這一創(chuàng)始性工作是在Poughkeepsie實驗室進行的，屬于Philip Carol領(lǐng)導(dǎo)的面向測試的設(shè)計項目。
Phil是軟件測試技術(shù)工作組(SW Test Technology Group)的一個系統(tǒng)測試工程師。這個工作組主要負(fù)責(zé)定義軟件測試技術(shù)和工具以用于整個公司。大概在30年以前，他們就開始意識到你不可能通過測試將質(zhì)量注于代碼中。你需要像考慮測試過程一樣也得考慮分析、設(shè)計和編碼