這是你已經做過的事,或者你知道一個好工具嗎?如何向我的團隊提供有關構建中包含的更改及其對風險的影響的反饋?
目標:幫助團隊瞭解最近的來源變化如何影響風險,以便他們知道在哪裏關注測試工作。隨時間提供數據並將其反饋到開發週期的規劃和範圍階段。
計劃: 結合與三葉草複雜度數據的svn變化數據在顯示上的複雜性或改變的風險的變化影響的報告(行×複雜=風險的#?)。這並不完美,但它可以幫助團隊更好地理解這些變化。
任何嘗試呢?如果是這樣,你使用了哪些工具,以及如何爲團隊提供這種線索?
這是你已經做過的事,或者你知道一個好工具嗎?如何向我的團隊提供有關構建中包含的更改及其對風險的影響的反饋?
目標:幫助團隊瞭解最近的來源變化如何影響風險,以便他們知道在哪裏關注測試工作。隨時間提供數據並將其反饋到開發週期的規劃和範圍階段。
計劃: 結合與三葉草複雜度數據的svn變化數據在顯示上的複雜性或改變的風險的變化影響的報告(行×複雜=風險的#?)。這並不完美,但它可以幫助團隊更好地理解這些變化。
任何嘗試呢?如果是這樣,你使用了哪些工具,以及如何爲團隊提供這種線索?
我的經驗是,測試和風險(S)時,新功能投入或缺陷時,固定標識。這一切都是在我所有的工作中「手動」完成的。
此致是一個有趣的想法 - 基本上插件/組件的CI服務器類型測試基於先前缺陷統計和變更後的文件的複雜分析的聚焦。
你很明顯需要一個代碼/文件的映射來測試用例,如果你有相反的結果(失敗的測試用例和被修改來修復的文件),你會有一些自動的方式來產生一些信息。
我懷疑是「風險」也可能包含「開發商」的組成部分。即一些開發人員對於簽入的風險比其他人有更高的「風險」 - 這對某些功能來說可能是本地的......在某些情況下,「開發人員」將是最重要的組成部分 - 要麼完全降低風險,要麼使之確定。
對於單元測試,我可能會生成該數據。對於集成測試和高級功能,我需要團隊將數據保持在最新狀態(這不是一件好事)。自動化,無處不在的系統似乎做得更好(只要他們有效地嘮叨) – 2009-06-04 17:56:19