作業: 判斷測試結果
這項作業說明如何精確地記錄測試發現以及所需要的延續動作。
規範: 測試
目的

這項作業的目的如下:

  • 製作已認知的產品品質之持續評估摘要
  • 指出及擷取詳細的測試結果
  • 提議適當的更正動作,以解決品質不良問題
關係
步驟
查驗所有測試發生事件與失敗情況
目的:  調查每一個發生事件,並對所產生的問題取得進一步瞭解。 

在這項作業中,需要分析「測試日誌」來決定有意義的「測試結果」,這是有關每項測試的預期結果和實際結果。逐一指出並分析每一個發生事件和失敗情況。盡可能瞭解每一個出現情況。

檢查重複發生事件、共同的症狀以及發生事件之間的其他關係。這些條件通常可以提供一組發生事件的主要原因之可貴透視。

建立及維護變更要求
目的:  將變更要求資訊輸入追蹤工具,供評估、管理及解析。 

其差異代表「目標測試項目」中的潛在問題,並且應該作為發生事件或變更要求輸入追蹤系統內,並指出應該採取的適當更正動作。

子主題:

驗證發生事件 頁面頂端

驗證確實有正確的支援資料可用。將資料分頁,以便直接附加在變更要求中,或可以分別取得資料的位置參照。

盡可能驗證問題確實可以重現。可以重現的問題比較可能會獲得開發人員的注意並加以解決;問題若無法重現時,不但會使開發人員感到受挫折,並且也會浪費寶貴的程式設計資源進行無謂的研究。我們建議您還是要記載這些發生事件,但要考慮將無法重現的發生事件和可以重現的發生事件分開來記錄。

澄清變更要求明細 頁面頂端

重要的一點是變更要求要容易瞭解,特別是其標題。請確定標題要簡單扼要,清楚指出特定的問題。簡短的標題對於摘要問題清單以及 CCB 狀態會議很實用。

變更要求的詳細說明不可含糊不清,並且要能容易解譯。最好盡快記載變更要求,但是在交給開發人員審查之前,也要花一點時間重看並增進及擴充說明。

盡可能提供一些候選的解決方案。如此可以減少說明中的其餘語義不明確問題,並且通常可以協助澄清事項。這也可以確保提高解決方案到您預期的層次。此外,這也可以顯示出測試小組不但是要找出問題,同時也樂於協助指出適當的解決方案。

其他應該包括的詳細資料為畫面影像、測試資料檔、自動化測試 Script、分析公用程式的輸出,以及會有助於開發人員找出及更正基礎錯誤的任何其它相關資訊。

指出相對的影響嚴重程度及解決優先順序 頁面頂端

向管理及開發人員提供問題的嚴重性指示。在大型的團體中,實際的解決優先順序通常是留待管理小組決定,不過您也可以讓個體指出他們偏好的解決優先順序,稍後再視需要加以調整。一般而言,我們建議您依預設值,為變更要求指定平均的解決優先順序,然後視每個情況,提高或降低其優先順序。

您可能需要將變更要求若不處理,會對正式作業環境產生的影響,以及變更要求若不處理時,會對測試工作產生的影響;重要的地方是管理小組不但要知道問題對測試的影響,以及對使用者的影響嚴重性。

有時很難事先看出為何需要兩種屬性。很可能發生事件很嚴重,例如系統損毀,但是卻不太可能會發生重新產生該問題的動作。在此情況下,小組可以指出嚴重性為高,但是表示低解決優先順序。

分別記載其他的變更要求

發生事件通常會彰顯出一句舊格言「事出必有因」;當您指出及記載某個變更要求時,通常會指出其他需要處理的問題。這時要避免試圖將這些額外的發現加入現有的變更要求中:如果這些資訊是和現有的問題直接相關,並且可以協助更輕易解決現有的問題則無妨。如果其他問題是不相關的,則在現有的 CR 中指出該問題時,可能會導致那些問題被忽略,無法獲得其應有的適當優先順序,或影響其他問題的處理速度。

分析及評估狀態
目的:  計算及提交測試的主要測量及指示符。 

子主題:

分散發生事件

依據發生事件的分散位置,例如功能範圍,品質風險,指定的測試員和開發人員等,來分析發生事件。

尋找分散型樣,例如問題計數超出平均值的功能範圍。同時也請找出工作過度,並且其成果品質未如理想的開發人員和測試人員

測試執行涵蓋面

若要評估測試執行的涵蓋面,您需要審查「測試日誌」以決定:

  • 在此測試循環中已經執行了多少測試(測試 Script 或測試案例),以及所有屬意的「目標測試項目」總數之比例。
  • 已成功執行的測試案例比例。

這裡的目標是要確保針對此測試循環設定的測試執行足夠的測試數目。如果做不到這一點,或無法增強執行資料,就可以依據下列項目,指出一或多個額外的測試涵蓋面準則:

  • 品質風險或優先順序
  • 規格型的涵蓋面(需求等)
  • 商業需要或優先順序
  • 程式型涵蓋面

請參閱概念:主要測試測量、需求型測試涵蓋面

將測試結果記錄及呈現在此測試循環的「測試評估報告」中。

變更要求統計資料

若要分析問題,您需要審查及分析選擇作為問題分析策略一部分的測量方式。最常用的一般問題測量方式包括下列幾種不同的測量方式(通常會以圖形格式顯示):

  • 問題密度 - 問題數目會顯示作業一或兩個問題屬性的函數 (例如分散在多個功能範圍,或是品質風險和狀態或嚴重性相比)。
  • 問題趨勢 - 問題計數會呈現為一段時間的函數。
  • 問題經歷時間 - 這是一種特殊的問題密度報告,會將問題計數顯示為一段期間內,問題仍維持給定狀態(開啟、新增、等待驗證等)的時間函數。

將這個測試循環的測量,和目前的反覆作業之執行總計,以及分析先前的反覆作業取得的總計相比,以更充分瞭解在一段期間內蘊釀出的趨勢。

建議您以圖解形式呈現結果,並佐以有關要求的發現。

評量目前的品質經驗
目的:  對軟體產品的現有認知或所經歷的品質提供意見回饋。 

製作現行品質經驗的摘要,並強調顯示軟體產品品質的好的一面和不好的一面。

評量未完成的品質風險
目的:  對哪些剩餘的風險區域會對專案造成最大的外曝可能,提供意見回饋。 

指出及說明就品質風險而言,尚未處理的區域,並指出這會對小組造成什麼影響和外曝。

提供指示,指出您認為每一個未完成的品質風險應該具有的優先順序,並使用優先順序來指出應該處理這些問題的優先順序。

評量測試涵蓋面
目的:  對測試涵蓋面分析做摘要評量。 

依據在測試執行涵蓋面步驟進行的工作,對資料代表的狀態以及資訊提供簡短的摘要陳述。

起草測試評估摘要
目的:  將測試結果和相關人員溝通,並對品質和測試狀態做客觀的評量。 

將此測試循環的測試結果呈現在「測試評估摘要」中。這個步驟是要製作起始的摘要草稿。這個動作是靠將先前收集的資訊,組合在一份易於閱讀的摘要報告中來達成。摘要的實際格式和內容可能會視關係人和專案的環境定義有所不同。

通常將起始的草稿分送給一部分的關係人,以取得意見回饋,以便在公佈給更多對象之前納入那些意見回饋,是很理想的做法。

向關係人通知主要發現
目的:  視需要促銷及公佈評估摘要 

使用任何適當的方法,公佈此項資訊。我們建議您考慮將這些資訊張貼在專案的中心位置,或在定期召開的會議中呈現這些資訊,以便能收集意見回饋以及決定下一步。

請注意將評估摘要公開,有時會是很敏感的政治性議題。請和研發管理人員商討結果的呈現方式,以便反映出誠實且精確的發現摘要,同時又能尊重開發人員的工作。

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

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

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

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



詳細資訊