Skip to content

欠陥マネジメント

発見された欠陥を確実にトラッキングし、修正・検証されるまで管理することはテストマネージャの重要な責務です。

欠陥のライフサイクルと単純な欠陥ワークフロー

Section titled “欠陥のライフサイクルと単純な欠陥ワークフロー”

欠陥管理システム(JiraやRedmineなど)を使用し、欠陥の状態(ステータス)を管理します。

  • 典型的な状態遷移:
    1. New (新規): テスト担当者が欠陥を報告。
    2. Open / Assigned (オープン/アサイン済み): 開発者に割り当てられ、修正作業中。
    3. Fixed / Resolved (修正済み): 開発者が修正を完了し、再テスト待ち。
    4. Closed (クローズ): テスト担当者が再テストを行い、修正を確認。
  • ライフサイクルには、「却下 (Rejected)」「延期 (Deferred)」などのステータスも含まれます。

機能横断的な欠陥マネジメント

Section titled “機能横断的な欠陥マネジメント”

欠陥のトリアージ(優先度や修正の要否を決定する会議)には、テストチームだけでなく、開発者、プロダクトオーナー、プロジェクトマネージャなどの機能横断的な代表者が参加する必要があります。これにより、ビジネス的価値と技術的リスクのバランスをとった決定が可能になります。

アジャイルおよびハイブリッド開発における欠陥マネジメント

Section titled “アジャイルおよびハイブリッド開発における欠陥マネジメント”

開発モデルによって欠陥の扱い方が異なります。

  • アジャイル開発: 見つかった欠陥は、可能であれば同じスプリント内で即座に修正されます。修正できなかったものはプロダクトバックログに追加され、ユーザーストーリーと同様に優先順位が付けられます。
  • ハイブリッド開発: コンポーネント開発チーム(アジャイル)とシステム統合テストチーム(ウォーターフォール)などの間で、欠陥のトラッキング方法やステータスの定義を統一することが課題となります。

欠陥レポート情報とプロセス改善への利用

Section titled “欠陥レポート情報とプロセス改善への利用”

欠陥データは、個別のバグ修正のためだけでなく、プロセスの継続的改善にも利用されます。

  • 根本原因分析 (RCA): なぜその欠陥が混入したのか(例:要件の曖昧さ、開発者の知識不足など)を特定し、将来のプロジェクトでの再発を防ぎます。
  • フェーズコンテインメント: 欠陥が混入したフェーズと発見されたフェーズを分析し、より早期(上流工程)で欠陥を発見できるようにレビュープロセスなどを強化します(シフトレフト)。