目的:
|
收集和檢查客觀的資料,以評估測試團隊所記載的問題和缺失。
|
從「變更要求」資料中指出重要的趨勢證據。通常不必在這項作業中浪費時間來分析資料量,更重要的是指出相對資料趨勢的意義。 尋找具有正面意義的跡象,例如穩定、連續發現缺失的比率,或發現率隨著時間微增或微降。
請注意發現率的尖峰與波谷,可能指出開發團隊正面臨流程、環境、政策或其他問題,導致生產力下降。
查看總結缺失的趨勢。觀察開發人員最後表示「無法重現」的情況是否明顯增加; 找出由於測試團隊的失敗分析不足而導致此問題的情況,並將此問題的程度量化表示。 查看開發人員最後以缺失「運作符合設計」做為總結的趨勢;
找出由於測試團隊的規格分析不足而導致此問題的情況,並將此問題的程度量化表示。 小心確認這些指示的真實性,不是因為開發人員太勞累而私下調派工作量。 因為在後續的建構版本中會向測試團隊發佈缺失修正,缺失驗證趨勢也需要做一些分析:
小心等待由測試團隊來驗證的缺失是否屯積太久或愈來愈多而難以管制。
找出其他表示有問題的趨勢。注意測試團隊如何記錄或管理缺失及其他變更要求: 含糊不清和不充分的變更要求資訊,很難讓開發人員採取行動。 團隊應該密切監督在缺失上記錄的資訊維持非常高的品質(以平均而言)。
抓住機會改善相關「變更要求」的明確性,避免語義不明確及情緒性的言語和推論。 與這些工作成果的建立者共同合作,清楚地陳述問題的本質,並引導找出實際和正確的方式來開始討論「議題」。
另外,請留意缺失在許多不同層面上分佈失衡的情形。尋找應用程式或規格中缺失發生率較低的功能範圍: 這可能曝露出該功能範圍已執行的測試不足。也請查看測試團隊成員的工作分配:團隊成員個人可能太操勞,以至於生產力下降。
|