目的:
|
將變更要求資訊輸入追蹤工具,供評估、管理及解析。
|
其差異代表「目標測試項目」中的潛在問題,並且應該作為發生事件或變更要求輸入追蹤系統內,並指出應該採取的適當更正動作。
子主題:
驗證確實有正確的支援資料可用。將資料分頁,以便直接附加在變更要求中,或可以分別取得資料的位置參照。
盡可能驗證問題確實可以重現。可以重現的問題比較可能會獲得開發人員的注意並加以解決;問題若無法重現時,不但會使開發人員感到受挫折,並且也會浪費寶貴的程式設計資源進行無謂的研究。我們建議您還是要記載這些發生事件,但要考慮將無法重現的發生事件和可以重現的發生事件分開來記錄。
重要的一點是變更要求要容易瞭解,特別是其標題。請確定標題要簡單扼要,清楚指出特定的問題。簡短的標題對於摘要問題清單以及 CCB
狀態會議很實用。
變更要求的詳細說明不可含糊不清,並且要能容易解譯。最好盡快記載變更要求,但是在交給開發人員審查之前,也要花一點時間重看並增進及擴充說明。
盡可能提供一些候選的解決方案。如此可以減少說明中的其餘語義不明確問題,並且通常可以協助澄清事項。這也可以確保提高解決方案到您預期的層次。此外,這也可以顯示出測試小組不但是要找出問題,同時也樂於協助指出適當的解決方案。
其他應該包括的詳細資料為畫面影像、測試資料檔、自動化測試 Script、分析公用程式的輸出,以及會有助於開發人員找出及更正基礎錯誤的任何其它相關資訊。
向管理及開發人員提供問題的嚴重性指示。在大型的團體中,實際的解決優先順序通常是留待管理小組決定,不過您也可以讓個體指出他們偏好的解決優先順序,稍後再視需要加以調整。一般而言,我們建議您依預設值,為變更要求指定平均的解決優先順序,然後視每個情況,提高或降低其優先順序。
您可能需要將變更要求若不處理,會對正式作業環境產生的影響,以及變更要求若不處理時,會對測試工作產生的影響;重要的地方是管理小組不但要知道問題對測試的影響,以及對使用者的影響嚴重性。
有時很難事先看出為何需要兩種屬性。很可能發生事件很嚴重,例如系統損毀,但是卻不太可能會發生重新產生該問題的動作。在此情況下,小組可以指出嚴重性為高,但是表示低解決優先順序。
發生事件通常會彰顯出一句舊格言「事出必有因」;當您指出及記載某個變更要求時,通常會指出其他需要處理的問題。這時要避免試圖將這些額外的發現加入現有的變更要求中:如果這些資訊是和現有的問題直接相關,並且可以協助更輕易解決現有的問題則無妨。如果其他問題是不相關的,則在現有的
CR 中指出該問題時,可能會導致那些問題被忽略,無法獲得其應有的適當優先順序,或影響其他問題的處理速度。
|