バグの操作
テストを実行して要件を検証する際には、バグが見つかります。 バグ作業項目を使用して、見つかったバグごとに進行状況を記述して追跡します。 バグ作業項目を作成する方法の詳細については、「バグの送信」を参照してください。 バグが見つかったら、このトピックのプロセスに従って優先度付けを行い、修正されたことを確認して、関係した作業および決定の記録を保持するようにします。
バグの作業項目フォームは、次の図に示すフィールドとタブにデータを保存します。
.png "CMMI のバグ作業項目フォーム")
.png "CMMI のバグ作業項目フォーム - タブ")
このトピックの内容
バグのトリアージ
バグの修正
バグの終了
バグのトリアージ
トリアージ会議は、プロジェクトの開発作業とテストの開始後に設定された間隔で行います。 会議を行う頻度と時間は状況によって異なります。
通常、バグのトリアージ会議はプロジェクト マネージャーが行い、チーム リーダーが出席します。場合によっては、ビジネス アナリストや特定のプロジェクト リスクについて発言できる関係者も出席します。 プロジェクト マネージャーは、新しいバグおよび再開されたバグのアクティブ バグ クエリを使用して、トリアージするバグの一覧を生成できます。
トリアージの開始前に、基準セットを策定して、修正する必要があるバグおよびその優先度を判断します。 基準では、通常、バグの重大度、価値 (または遅延のオポチュニティ コスト) の高い機能に関連付けられたバグ、またはその他のプロジェクト リスクを特定します。
トリアージの基準は、チーム プロジェクトのドキュメント フォルダーに格納する必要があります。 時間の経過に伴い、ドキュメントは更新されます。 プロジェクトのバージョン コントロールが有効になっており、任意の時点にプロジェクトで使用されている特定の基準を監査と評定の証拠のために取得できることが前提です。
多くの場合、プロジェクトの初期の段階で、トリアージしたバグのほとんどを修正するように決定します。 ただし、プロジェクトが進むにつれて、トリアージの基準を引き上げて修正するバグの数を減らす場合があります。
トリアージの基準を引き上げて報告されたバグを修正しないままにすることは、 バグを修正することよりも、プロジェクト スコープ、予算、およびスケジュールを満たすことの方が重要であるというトレードオフです。
基準を使用して、修正するバグ、およびその [状態]、[優先度]、[深刻度]、およびその他のフィールドの設定方法を判断します。 既定では、テンプレートに 1 ("修正が必要") から 4 ("重要でない") までの 4 つの優先度が用意されています。 プロセス テンプレートで定義を変更する場合は、それに応じてガイダンス、ヘルプ テキスト、および基準ドキュメントを更新する必要があります。
バグ作業項目を入力する方法の詳細については、「バグ (CMMI)」を参照してください。
バグの修正
バグのトリアージを行って優先度を付けたら、バグを詳しく調べるために開発者に割り当てます。
バグ作業項目には、バグを再現するために必要な情報を提供する [ステップの再現] タブがあります。 ただし、難しいバグの再現に役立つ IntelliTrace を使用できる場合もあります。 IntelliTrace の詳細については、「診断トレース データへの再現が困難なバグの組み込み」および「IntelliTrace を使用したデバッグ」を参照してください。
開発者は、処理方法を決定したらその決定事項をバグ作業項目に書き留めます。
修正の決定
開発者は、他のチーム メンバーと協力して作業し、他のコード セクションに影響する修正および大規模な回帰テストを必要とする可能性がある修正を推奨する場合があります。 このような修正のリスクの評価に関連する話し合いは、バグ作業項目の履歴に記録します。監査または SCAMPI (Standard CMMI Appraisal Method for Process Improvement) 評定に役立つ決定分析およびリスク管理の証拠が文書化されるためです。 CMMI の詳細については、「CMMI の背景」を参照してください。
バグ修正の単体テストの更新および実行
単体テストでは、コードの単位が正しく実装されていることを検証します。 単体テストを記述して実行すると、テストの開始前にバグが特定されるので、品質管理のコスト削減に役立ちます。 開発者は、開発タスクの実装またはバグ修正の実装の一環として記述されるすべてのコードの単体テストを記述する必要があります。 詳細については、「単体テストを使用したコードの検証」を参照してください。
テスト ファースト開発戦略では、コード修正を行う前に単体テストを記述することが望ましい場合があります。 この種の戦略は、アジャイル ソフトウェア開発者に好まれます。 CMMI では、特定のシーケンスで単体テストを記述する必要はなく、機能が効果的に検証されることだけが求められます。
単体テストが記述されて実行されたという証拠が CMMI 評定には必要です。 必ずテストをコード修正のタスク作業項目にリンクし、このようなタスクをバグ作業項目にリンクするようにしてください。 これにより、SCAMPI リード評定者が求める証拠を追跡できるようになります。
バグ修正のコードのレビューおよびリファクタリング
コード レビューは、新しいコードまたは変更されたコードをデイリー ビルドに統合する前に、コードが確立された品質基準を満たすことを確認するために使用されます。 品質に関する考慮事項には、コーディング規則、アーキテクチャと設計への準拠、パフォーマンス、読みやすさ、およびセキュリティがあります。 また、コード レビューを使用すると、コードの記述方法に関する他の開発者からの追加情報も把握できます。 コードをレビューおよびリファクタリングする方法の詳細については、「開発タスクの実装」を参照してください。
バグの終了
バグが修正されたら、バグ作業項目を終了する前に、問題が解決されたことを検証するためにテスト担当者にバグを割り当てます。
修正の検証
修正を検証するために、テスト担当者は、バグを再現したりその他の予期しない動作を探したりすることを試みます。必要に応じて、バグの再アクティブ化も試みます。
バグの解決の検証時に、バグが完全に修正されていないことが判明する場合、または解決に同意できない場合があります。 この場合、バグの解決者とバグについて話し合い、合意に達してから、場合によってはバグを再アクティブ化してください。 バグを再アクティブ化する場合は、バグの説明にバグを再アクティブ化する理由を含めて、情報が保持されるようにしてください。
バグ作業項目の終了
バグはさまざまな理由で終了します。 単純な例では、バグを修正済みとして検証したところで、そのバグを終了することもできます。 ただし、バグは製品の次のバージョンまで延期されたり、再現できないと証明されたり、重複として確認されたりすることがあります。 これらの理由は、それぞれ文書化する必要があります。バグを正しく終了して、終了した理由について混乱が生じないようにする必要があります。