作業: 評估與改進測試成果
這項作業的重點是及時變更測試工作以提高效率。
目的

這項作業的目的如下:

  • 評估測試的工作的生產力、效率及達成率
  • 調整測試工作(作法和策略上)以提高效率
關係
步驟
捕捉工作狀態
目的:  客觀地、及時地對照計劃來掌握測試工作的整體狀態。 

這個步驟有各種不同的執行方法,且方法大多視您的專案文化而定。 可能的話,請收集和比對由團隊各成員或次級團隊所準備的進度報告。 專案時間表也是一種可參考的資料。在積極使用並以實際進度來更新專案時程規劃系統(例如 Microsoft Project)的情況下,這也是另一種可用的資訊來源。 在可用和積極使用的情況下,也可能從配置和變更管理系統中導出客觀的狀態或進度測量值。

在此步驟及後續關於收集資訊和評估測試工作的步驟中,請儘量秉持客觀的心態,應該同時兼顧客觀和主觀的衡量。 請記得,目標數目只能提供整個圖片的一部分,並且必須能用目前的專案「氣候」支持及解釋。反過來說,別讓測試工作完全依賴在傳聞和主觀的臆測上:請尋找有力的客觀證據。 我們建議您要透過和小組負責人,或如果可能的話,和各個小組成員進行討論來收集主觀的評定,以補充您的客觀資料,並拿捏客觀資料的可信程度。

收集測試工作的生產力和效率測量值
目的:  收集和檢查客觀的資料,以評估測試團隊所執行的測試。 

調查在測試的指定、定義、設計、實作及執行上已付出多少努力。 小心別過份投入測試工作的某一方面而損及其他方面。 也要注意哪些方面可能徒勞無功或不划算。

另外也要注意測試的效率。尋找支持初步效率觀察的數據。 考量缺失發現率、缺失嚴重計數、重複缺失統計值及發現測試遺漏的缺失等方面。

收集變更要求的分佈、趨勢及經歷時間測量值
目的:  收集和檢查客觀的資料,以評估測試團隊所記載的問題和缺失。 

從「變更要求」資料中指出重要的趨勢證據。通常不必在這項作業中浪費時間來分析資料量,更重要的是指出相對資料趨勢的意義。 尋找具有正面意義的跡象,例如穩定、連續發現缺失的比率,或發現率隨著時間微增或微降。 請注意發現率的尖峰與波谷,可能指出開發團隊正面臨流程、環境、政策或其他問題,導致生產力下降。

查看總結缺失的趨勢。觀察開發人員最後表示「無法重現」的情況是否明顯增加; 找出由於測試團隊的失敗分析不足而導致此問題的情況,並將此問題的程度量化表示。 查看開發人員最後以缺失「運作符合設計」做為總結的趨勢; 找出由於測試團隊的規格分析不足而導致此問題的情況,並將此問題的程度量化表示。 小心確認這些指示的真實性,不是因為開發人員太勞累而私下調派工作量。 因為在後續的建構版本中會向測試團隊發佈缺失修正,缺失驗證趨勢也需要做一些分析: 小心等待由測試團隊來驗證的缺失是否屯積太久或愈來愈多而難以管制。

找出其他表示有問題的趨勢。注意測試團隊如何記錄或管理缺失及其他變更要求: 含糊不清和不充分的變更要求資訊,很難讓開發人員採取行動。 團隊應該密切監督在缺失上記錄的資訊維持非常高的品質(以平均而言)。 抓住機會改善相關「變更要求」的明確性,避免語義不明確及情緒性的言語和推論。 與這些工作成果的建立者共同合作,清楚地陳述問題的本質,並引導找出實際和正確的方式來開始討論「議題」。

另外,請留意缺失在許多不同層面上分佈失衡的情形。尋找應用程式或規格中缺失發生率較低的功能範圍: 這可能曝露出該功能範圍已執行的測試不足。也請查看測試團隊成員的工作分配:團隊成員個人可能太操勞,以至於生產力下降。

收集可追蹤性、涵蓋率及相依關係測量值
目的:  收集和檢查客觀的資料,以評估資產的可追蹤性。 

在測試資產(測試構想、測試案例、測試 Script、測試套組及變更要求)與相關的上下游資產之間分析追蹤關係的狀態。 查看測試工作是否以正確的領域為重點,並尋找一套可行的激勵機制。 另外,請查看負面的跡象,可能暗示有某些測試方面遺漏或已不重要: 如果需求或開發團隊已偏離目前測試工作所針對的領域,則值得注意。

評估測量值及制訂初步評量
目的:  導出和評估測量值資料,並制訂初步評量,對照計劃來衡量測試工作的效率。 

核對您已收集的所有資訊,進行整體評估。切記,收集的每一項資料只表達整體評量的某一個觀點, 您必須根據所有資料,以一種均衡、深思熟慮的觀點來制訂測試工作的評量。

以適合關係人評論和提出意見的方式來記錄您的初步評量。

記錄調查結果
目的:  載明摘要調查結果以納入專案管理報告中,並對照先前的評量來分析後續的狀態評量。 

這項作業會提供狀態摘要資訊,此資訊對於專案經理及管理團隊中的其他角色很重要。 這些角色會利用摘要調查結果來制訂有關專案的優良決策。

建議您在記錄測試評量的某些方面時,採取可比較和對照後續評量與先前評量的格式。 這可讓您分析測試工作隨著時間改善的相對趨勢。

發表評量並聽取意見
目的:  訪問關係人並聽取他們對於實際測試工作是否滿足需求的意見。 

提出的評量結果給關係人評論和發表意見。這在每個專案中的方式或作法各有不同: 有時是一連串非正式的交談、有時是直接張貼在企業內部的專案網站上、有時是正式的簡報會議 - 請根據專案文化來選擇適合的方式。

即使有最好的計劃和規格文件,但這些文件的最初期望和意圖,通常不同於產生的最終產品。 無論是測試和評估軟體,還是軟體開發本身,情況的確如此。 此步驟的價值是利用機會取得關係人的意見,並指出謹慎的計劃和文件尚未滿足哪些最初的預期或意圖。

規劃和實作改善提案
目的:  指出有待改善之處,並制訂達到改善的初步策略。 

根據您的分析和取自於各種關係人的意見,找出有待改善之處。 設法讓測試更有效用、生產力及效率。作法包含:重新分派人員,包括成立搭檔來提高工作效率,或聘雇專業的承包商; 利用生產力工作來提高效率;尋求替代方案和技術,更有效地找出缺失。

在某些情況下,最好少量、逐步地改善測試工作,別冒險以重大、擾人的變動來打亂專案:有時重大的改變反而正當且有用。 請以最佳的判斷力來設計適當的改善方法,並與其他管理人員討論您的想法,聽取意見,再交由團隊貫徹重大的改變。

監督和支援改善提案
目的:  確保圓滿、及時地實現必要的改善提案。 

為了有效地改善,您必須管理改善的結果。設法監督改善提案 - 最好在正式通過之前 - 以評估有效性。 自己主動地監督採納變更的進度,或指派團隊的其他人來負責。

大多數的變更都會遭遇阻力或問題,必須克服,最後才能成功。預留足夠的時間或立即快速解決任何導致提案失敗的問題。 注意人們天生對於變更的反抗性,設法適當地解決他們的疑慮。

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

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

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

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



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