ビルドに含まれる変更とリスクへの影響についてチームにフィードバックするにはどうすればよいですか？

Question

これはあなたが既にやっていることですか、それとも良いツールを知っていますか？

ゴール：ヘルプチームは、最近のソース変更がリスクへの影響を把握し、テストの取り組みにどこに焦点を当てるかを理解します。時間の経過とともにデータを提供し、開発サイクルの計画段階と範囲設定段階に戻します。

PLAN： が複雑または変化のリスク上の変化の影響を示すレポートにクローバーの複雑データとSVN変化データを結合（ラインX複雑=リスクの位？）。完璧ではありませんが、チームが変化をよりよく理解するのに役立ちます。

誰でも試してみてください。もしそうなら、どんなツールを使いましたか、どのようにチームにこのキューを提供しましたか？

Answer 1

私の経験では、新しい機能を導入したときや欠陥が修正されたときにテストとリスクが確認されています。これは私のすべての仕事ですべて "手動で"行われました。

あなたの興味深いアイデアは、基本的に、以前の欠陥の統計と変更されたファイルの複雑さの分析に基づいてテストに焦点を当てるプラグイン/コンポーネントのCIサーバータイプです。

ケースをテストするには、明らかにコード/ファイルのマップが必要です。逆の場合（テストケースが失敗し、修正を行うために変更されたファイル）、いくつかの自動生成方法があります情報。

「リスク」に「開発者」コンポーネントが含まれている可能性があります。つまり、一部の開発者は他よりも本質的に高い「リスク」を持っています - そして、これは一部の機能にとってもローカルかもしれません...場合によっては、 "開発者"が優先的な要素になるでしょう - リスクを完全に減らすか、 。