作業: 識別測試目標
這項作業說明如何指定需要測試的個別系統元素,包括軟硬體。
關係
步驟
決定實作什麼軟體
目的:  瞭解開發團隊在即將展開的排程中的主要交付項目。 

利用「反覆計劃」和其他可用的來源,指定開發團隊計劃在即將展開的「反覆」中要生產的個別軟體項目。 由於開發工作分散在各地的團隊,您可能需要直接與每一個團隊討論開發計劃。 瞭解是否有任何開發工作已轉包,並透過任何管道來收集轉包商開發工作的詳細資料。

除了新的軟體,也要注意基礎架構和共用元件的變更。這些變更可能影響先前開發週期所生產的其他相依或相關軟體元素,一定要測試這些變更對這些元素造成的影響。 同樣地,對於開發工作打算利用的協力廠商元件,您應該指出任何變更和新增內容。 這包括共用元件、基本或一般程式碼庫、GUI 小組件、持續性公用程式等。 審查軟體架構,判斷正在使用的哪些機制可能受到協力廠商元件變更的影響。

指定要測試的候選系統元素
目的:  指定應該進行測試的目標項目。 

對於每一個指定的測試激發因素,檢查此開發週期要交付的軟體項目清單。 建立初步清單,排除無法滿足測試激發因素的任何項目。 記得納入可用的商用軟體及要直接由專案開發團隊來開發的軟體。

您也可能需要考量各種目標部署環境對於要測試的元素有何影響。 應該擴充候選系統元素的清單,納入正在開發的軟體及目標環境的候選元素。 這些元素將包括硬體裝置、裝置驅動程式軟體、作業系統、網路和通訊軟體、協力廠商基本軟體元件 (例如 電子郵件用戶端軟體、網際網路瀏覽器等). 也包括與上述所有元素的可能組合有關的各種配置和設定。

由於已確定重要的目標部署環境,您應該考慮建立或更新一或多個概略的「測試環境配置」來記錄這項資訊; 此概要應該提供名稱、簡要說明,並列舉配置的主要需求或特性。 請別將太多時間花在這些概要上;後續在作業:定義測試環境配置中會詳述需求和特性的清單。

修正目標項目的候選清單
目的:  從測試工作計劃中刪除不必要的目標(及加入遺漏的元素)。 

根據與評估關係人在測試工作上達成共識的評估任務和範圍, 檢查目標項目的清單,並指出未滿足評估任務且很明顯超出測試範圍的項目。

進行反向檢查,嚴格地再一次檢查項目,質問修正的目標項目清單是否確實滿足評估任務和測試工作範圍。 可能需要在目標項目清單中加入其他元素,以確保有適當的範圍和能力可達成評估任務。

定義目標項目的清單
目的:  表達在即將展開的工作上針對目標測試項目所做的決策。 

現在已決定目標測試項目,您必須向測試團隊及測試工作的其他關係人表達您的選擇。 最常見的方法是將目標項目的決策記錄在「反覆測試計劃」中。

另一種作法是將這項資訊記錄在某種形式的表格或試算表中,以此來主導工作和責任分配。 在測試實作和執行期間,關於要實作的特定測試,以及在這些目標項目上要捕捉什麼測試結果, 個別的測試人員會利用這項資訊來制訂策略性決策。

評估及驗證結果
目的:  驗證作業已適當完成,並且產生可接受的工作成果。 

現在您已經完成工作了,這時最好驗證該項工作確實具有足夠的價值,而不只是花費在大量紙上作業。您應該評估您的工作是否具有適當的品質,並且該工作的完成狀態可以讓團隊的其他成員用作他們的後續工作之輸入。請盡可能使用 RUP 提供的檢查清單,來驗證品質和完成狀態都「夠好」。

請邀請執行下游作業而必須以您的工作成果作為輸入的人參與審查您的暫時性工作。請在您仍有時間採取動作來處理他們關心的問題時執行這個動作。您同時也應該將您的工作和關鍵的輸入工作成果做評估,以確定您已經正確且適當地重新呈現那些工作成果。 在這個基礎上,邀請輸入工作成果的作者審查您的工作,會有助於您評估您的工作成果。

請記得 RUP 是一項反覆式的交付程序,在許多情況下,工作成果都會隨著時間而演進。因此,通常並不需要(通常是缺乏生產力)對只會在緊跟在後的後續工作中用到一部分,或甚至於完全用不到的工作,做出完整的工作成果。這是因為和工作成果相關的狀況極可能會變動,因此在建立工作成果所做的假設狀況就變成不正確,導致浪費許多人力物力以及成本高昂的重做。同時也要避免浪費太多時間在呈現方式上,而導致損害內容本身的價值。在呈現方式佔極大的重要性,並且可以提交專案就具有商業價值的專案環境中,您可以考慮將呈現工作交給管理資源來做。



內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊