作業: 定義評估與可追蹤性需求
這項作業說明如何定義評量和追蹤需求,以及應該遵循的整體策略。
關係
角色主要: 其他的: 協助:
輸入強制: 選用: 外部:
輸出
步驟
指出評量和追蹤需求
目的:  瞭解軟體評估流程的交付項目並導出相關的需求。 

審查「反覆計劃」,指出此即將展開的重要工作有何特定評量需求。詢問關係人對於評量和追蹤有何需求。

另外,考量在測試工作期間或結束時是否要正式審核測試工作。 正式審核需求可能要求保留其他文件和記錄,以證明已執行足夠的測試。

考量限制
目的:  指出會影響是否(或必須)實作需求的限制。 

經常會有一大堆永無止境的「慾望」很容易視為可追蹤性和評量策略的需要, 但應該以最重要的「需求」為重點:a) 提供實質的資訊給專案小組 b) 可以實際追蹤和測量。 不太可能有足夠的資源可讓您的策略去滿足超過基本的需求。

子主題:

合格品質水準頁面頂端

規定什麼品質水準視為「優良」和開發適當的評量策略很重要。 請注意,在整個專案生命週期,品質範圍的重要性通常會變化,品質水準也會隨著關係人的觀點而起伏。

審查 QA 計劃、審查「軟體開發計劃」及直接訪問重要的關係人,判斷他們以什麼標準做為合格品質水準。

流程和工具輔助 頁面頂端

您可能幻想著在低階程度上輕鬆地追蹤和評量,但實際上很難實作這種方法,且通常不划算。 就算有精確的工具支援,管理低階的追蹤方法仍然很困難且費時;如果沒有支援工具,則幾乎不可能。 軟體工程流程本身就可能限制可追蹤性:比方說,如果需要從測試追蹤到動機需求, 但需求本身未妥善管理,則可能難以實作此可追蹤性。

請考量軟體工程流程和工具的約束和限制,從而選擇適當、可行的追蹤和評量方法。

考量可能的策略
目的:  指定並描述一或多項策略,以推動必要的評量流程。 

您已更瞭解評量和追蹤需求,以及由期望品質水準和可用的流程與工具支援所加諸的限制, 現在需要考量您可以採取的評量或評估策略。 如需可能的策略的詳細作法,建議您閱讀 Cem Kaner 的 "Measurement of the Extent of Testing"(2000 年 10 月)。(取得 Adobe Reader

子主題:

測試涵蓋率分析 頁面頂端

測試涵蓋率有許多不同的方法,任何一個單獨的涵蓋率測量法所提供的涵蓋率資訊,不足以滿足評估測試工作的範圍或達成率的需求。 請注意,不同的涵蓋率策略多少都需要實作,對於任何特定的測量種類, 通常有一定的涵蓋率分析深度,達到此深度之後,就不值得再記錄更多詳細資訊。

測試涵蓋率測量法的一些種類包括:需求、程式碼、產品權利及標準。 建議您在測試評量策略中考慮納入多個涵蓋率種類。 在大多數情況下,測試涵蓋率就是最初規劃和實作特定的測試。 不過,測試涵蓋率測量值和分析也適合與測試結果或缺失分析一起考量。

測試結果分析 頁面頂端

測試結果分析的常見方法是直接參考正面或負面的結果在已執行的測試總數中所佔的百分比。 綜合我們的意見和其他測試業者的意見,這種分析測試結果的方法太簡化且不完整。

我們倒是建議您依據一段時間的相對趨勢來分析測試結果。 在每一個測試週期內,請考量測試失敗在不同層面上的相對分佈情形, 例如正在測試的功能範圍、探索的品質風險類型、測試的相對複雜性及每一個功能範圍上運用的測試資源。

缺失分析 頁面頂端

雖然缺失本身很明顯與測試工作的結果有關,但對於測試工作的進度或工作的完成性和完整性,缺失資料的分析無法提供任何有用的資訊。 然而,有些測試團隊和專案經理會誤以目前的缺失計數來測量測試進度,或視為一項標準來衡量開發的軟體品質。 綜合我們的意見和其他測試業者的意見,這種作法毫無意義。

相反地,建議您分析缺失在一段時間上的相對趨勢,以提供相對穩定性的測量。 例如,假設測試工作一直相當固定,則在固定期間測量的新缺失發現率,通常會在反覆期間呈現「鐘形曲線」; 遞增的發現率會先達到尖峰,然後在接近反覆結束時下降。 不過,您需要搭配其他缺失測量值的分析來提供這項資訊,例如:缺失解決比例,包括解決類型的分析、缺失的嚴重性分佈、缺失的功能範圍分佈。

利用更準確的工具支援,可以相當輕鬆地完成缺失資料的複雜分析;如果沒有適當的工具支援,問題會非常棘手。

與關係人討論可能的策略
目的:  透過初步的關係人評論來收集意見,必要時調整策略。 

向各種關係人說明可能的策略。這通常是由下列角色組成的一群人: 專案經理、軟體架構師、研發經理、系統分析師、配置與變更經理、部署經理及客戶代表。 每一個角色對於如何評估品質都有發言的權利。

您應該根據專案的文化,選擇適當的方式來表達可能的策略。 可能分為一或多次非正式的會議,或舉行正式的簡報或研討會。

定義並同意評量策略
目的:  說服關係人同意將要採取的策略。 

採納從討論中獲得的意見並修正評量策略,建立單一策略來解決所有關係人的需求。

提出評量策略來取得最後的協議和認可。

定義工具需求
目的:  定義支援工具的配置需求,以執行評量流程。 

如先前所述,利用更準確的工具支援,可以相當輕鬆地完成測量資料的複雜分析;如果沒有適當的工具支援,問題會非常棘手。

對於下列種類,請考量您需要什麼工具支援:涵蓋率和可追蹤性、缺失分析。

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

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

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

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



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