本文來自于 Rational Edge：在對軟件迭代開發生命周期中的測試人員的作用進行探討的同時，作者考慮，除了 RUP 測試規程中提供的描述，測試人員還能如何對項目做出廣泛的貢獻。
從測試工程師那里聽到的最普遍的抱怨是直到過程中很晚的時候才能有效地參與到軟件開發項目中。此外，測試通常是在開發人員在抗爭損壞一個接一個版本候選的很晚出現的缺陷時所逼出的行為。到一個合適的候選版本出現的時候，測試人員已經成為瓶頸，顯然，要對進一步的延遲負責。
Rational Unified Process®，或 RUP®，廣泛地概括了測試規程（Test Discipline），并介紹了測試角色如何及早地參與項目生命周期。
我希望在本文中介紹另一種觀點。代替由測試規程開始，我將依次考慮每個 RUP 階段的風險管理原則，并詢問經驗豐富的測試人員，為了促進那些目標他們可能會做些什么。雖然測試工程師不能估算總的項目成本，但是他們的確可以評估對成本的測試貢獻，并且提出測試風險和可行性。雖然他們不應該計劃解決方案架構，但是他們可以幫忙度量。雖然測試人員不構建一系列可執行程序，但是他們可以評估每個可執行程序如何表示一個從前一個而來的進展。雖然測試人員不構建最終的候選版本，但是他們可以確保具有可接受的質量。
我相信在 RUP 的每個階段，測試人員都有機會對項目做出大量貢獻。該貢獻遠遠地擴展了，例如，要求更早地測試交付內容 —— 或者更早地執行一組標準的測試 —— 比傳統的瀑布驅動過程中。本文應作為面向開發團隊中的測試人員的 RUP 原則的激勵說明來閱讀。它不應該作為 RUP 測試規程的概要或初級讀物。雖然我相信許多測試人員會覺得該信息很有用，但是我還相信管理人員將會對看到測試人員的能力和經驗如何在 RUP 項目的所有階段中更有效地應用感興趣。
初始（Inception）階段：管理業務風險
RUP 的初始階段是對準業務風險的管理。為了制定出自該階段的可行或不可行的決策，我們需要了解
待解決問題的性質。
解決方案的價值，不論是就節約或收益而言，還是以一些其他的業務價值，如質量或時間性而言。
潛在的解決方案，因此我們至少知道問題是可解決的。
對解決方案的粗略成本估算。
危害解決方案的風險。
帶著此信息，涉眾被聚集到生命周期目標（Lifecycle Objectives，LCO）會議上。如果項目被視為是可行且值得做的，那么項目會繼續進入精化階段。
評估成本
可行性和成本是 LCO 會議上的重要因素，并且測試人員無疑可以為該決策貢獻重要的數據。測試人員可以估算對成本的測試貢獻，甚至有時候可以有助于可行性問題。記住，在初始階段中，盡管我們只對球場的數字感興趣。過高的精確度將給我們帶來不真實精確度的不適當安全感。
也許有或也許沒有實際的可執行程序作為 LCO 簡報的一部分。這些可能由技術示范者、現有產品的快速出租，或者也許是更實質的東西組成。我的意見是在如此初步的階段執行如此正式的操作是不適當的。
因為測試成本對總的開發成本做出貢獻，所以我已經列出許多對測試成本做出貢獻的行為。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
