基于DAD方法的IBM敏捷開發過程中的敏捷管理(2)

　　為了減少測試工具Z將無法有效地執行應用程序的回歸測試的風險，我們將在即將到來的迭代中使用它。

　　風險評估實際上是一個持續的過程，而不是一個只發生在特定的時間的過程。至少，你應該在迭代或一個里程碑抵達時評估風險。重新聚焦迭代目標時重新評估風險，尤其是:

　　消除掉已經完全緩釋、不在存在的風險

　　尋找、發現那些新近引入的風險

　　重新評估的風險值和重新排列的風險列表

　　如果可能的話，請每周都重新審視你的風險清單，看看他們都發生了什么變化。讓最靠前的十大風險可以在整個項目過程中保持足夠的曝光度、可見度，并堅持采取、執行風險應對的計劃和行動。通常，你應該將風險狀態評估報告附加到你的周報、月報(如果有)的簡報中去。

　　監控和管理測試(Monitor& Control Test) - 既然是敏捷方法，為什么還需要監控和管理呢?我前面說過，在企業環境適當的紀律和度量是有幫助的。就如我們所看到的DAD方法中，構建迭代的質量管理和測試工作經由核心團隊和獨立測試團隊負責，而且顯然在不同時期(迭代、軟件生命周期的不同階段)均有不同的測試關注點。為了使得測試工作條理清晰、資源充分利用、團隊目標的適時調整需要從全局測試的角度基于規劃;為了在測試工作中贏得寶貴時間和準確的調整測試策略，我們需要對測試工作進行監控和管理。

　　測試工作量的監控 – 這個任務的重點是對于測試工作的進展狀態、測試工作工作量、測試狀態監控，以提高測試有效性為目的適時調整。應該評估你的工作是否是適當的質量，而且它是完全夠用，且后續將利用它作為質量評價工作。如果可能的話，使用檢查表，以驗證質量和完整性是否足夠好。

　　圖3. 隨時更新的測試進展狀態報告

　　尋找積極的跡象，如發現缺陷的穩定，持續率，或隨著時間的推移持續增加或減少的規律。尋找尖銳波峰和波谷的出現點，這表明測試團隊可能會遇到的政治、過程、協作方面的壓力，我們需要適時給出支持和問題的解決方案。

　　看看缺陷閉合的趨勢。確定當下情況這里有沒有測試關閉待驗證不足的問題，或者開發修復問題不充分性的問題。量化和分析， 因為開發者標記缺陷為“不可再現(Notreproducible)”來關閉問題的趨勢，和分析問題的嚴重程度。分析缺陷因為“代碼按設計工作 (work as design)”被開發者關閉的數量和趨勢等。請注意，在這些問題凸顯的時候，關注是否因為過度的開發工作量、或者因為害怕審查他們的工作而采取的行動所致。您也應該分析的缺陷確認趨勢，分析修復缺陷又再次引入新缺陷至后續版本中的問題?？偠灾?，從趨勢分析可以得到發現團隊工作效率降低、個別隊員超負荷工作和藉此改善團隊協同的機會。

　　測試覆蓋范圍監控 – 這個任務的重點是對于迭代、版本測試工作的覆蓋范圍、測試組織充分的監控;以及判斷跨迭代的獨立測試團隊與迭代內團隊自主測試的配合是否恰好充分，測試的增量計劃是否滿足了增量型開發持續增長的需求。

　　測試覆蓋有功能點覆蓋、也有配置和測試環境的覆蓋，有效的了解測試的覆蓋程度需要類如RQM(Rational Quality Manager)這樣的工具，幫助設計測試覆蓋規劃，以及監控測試實際覆蓋狀況。

　　圖3. 設計最佳的覆蓋面和最高效的執行路徑

　　將度量測試覆蓋率的公式集成如工具，例如RQM，RTC，可以回答“測試完成了%多少?多少設計的測試案列還沒有被測試過?多少需求和功能點還未和相應的計測試用例關聯?”最為常用的測試覆蓋度量矩陣是“單元測試的代碼覆蓋率”。.

　　任何有計劃的測試任務至少基于描述過的一個測試覆蓋策略。覆蓋策略指導著測試者的測試用例設計?；谛枨蟮臏y試覆蓋率可能已足以產生測試完整性的量化評定了。例如，如果所有的性能測試的要求已被確定，然后所有測試執行的結構可以關聯需求，則很可能得到性能測試要求的75%已被驗證的結論。

　　類似的，如果基于代碼的覆蓋技術被應用。這種類型的測試覆蓋率就可能足以說明系統的白盒測試覆蓋率，這也是目前大多數企業和企業所認可的。

　　這兩種測試覆蓋的策略可能需要人為干預，而最佳的方式我認為是通過系統自動化抽取數據形成報告，盡量避免引入人為因素最為科學。

　　測試工作個人儀表 – 個人儀表盤首要的工作是讓個人在工作中以最小的代價了解自己的工作進展、合理安排自己的工作。個人儀表盤的是以人為本、團隊自我管理的初衷來設計的，將質量和測試監控的度量指標和個人儀表盤的視圖規則聯系起來，個人就能夠更有紀律的完成自己的工作，配合團隊和項目的整體進度。每個人也非常清楚自己工作對整體所產生的影響，了解自身的價值，幫助建立自我認同感。

　　圖3. 測試者根據團隊規則和個人意愿設計的個人儀表盤

原文轉自：http://www.kjueaiud.com