バグ管理図とは？テスト進捗・累積バグ件数・未解決バグの読み方【基本情報技術者試験】

まず結論

バグ管理図では、線の高さだけではなく、テストの進み具合とバグの増減を組み合わせて読むことが大切です。

基本情報技術者試験では、特に次の2パターンを押さえます。

テスト終盤で累積バグ件数の増え方が小さくなる
→ 新しく見つかるバグが減っている
→ 品質が安定する方向

テスト終盤でも累積バグ件数が急増する
→ バグがまだ見つかり続けている
→ 未発見バグが多く残っている可能性

また、未消化テスト項目数や未解決バグ数も合わせて表示される場合は、テストや修正そのものが止まっていないかも確認します。

「目標バグ件数に達した = テスト完了」とは限らない。終盤の傾きとテスト進捗を見る。

直感的な説明

バグ管理図は、ソフトウェアテストの健康状態を確認するメーターのようなものです。

テストが進めば、一般には次のような変化が起こります。

テストを実施する
→ 未消化テスト項目数が減る

バグを見つける
→ 累積バグ件数が増える

バグを修正する
→ 未解決バグ数が減る

ここで重要なのが、テスト後半で新しいバグがどれくらい見つかっているかです。

品質が安定してくれば、新しく発見されるバグは徐々に少なくなることが期待されます。

テスト前半
→ バグが多く見つかる

テスト後半
→ 新しいバグが減る
→ 累積バグ件数の曲線が横ばいに近づく

反対に、テスト項目をかなり消化した後でも曲線の傾きが大きいなら、まだ多くの不具合が潜んでいる可能性があります。

定義・仕組み

バグ管理図では、テストの進行状況とバグの状態を複数の指標で確認します。

代表的な指標は次のとおりです。

指標	意味	一般的な読み方
テスト消化件数	実施済みのテスト項目数	増えるほどテストが進んでいる
未消化テスト項目数	まだ実施していないテスト項目数	最終的には減っていく
累積バグ件数	これまでに見つかったバグの合計	増えるが、終盤は増加が緩やかになるのが望ましい
未解決バグ数	発見済みだが未修正のバグ数	最終的には減っていく

累積バグ件数の傾き

累積バグ件数は、バグを発見するたびに増えるので、基本的には右肩上がりになります。

見るべきなのは、増えているかどうかではなく、増えるペースです。

傾きが大きい
→ 短い区間で多くのバグが見つかっている

傾きが小さい
→ 新しく見つかるバグが少なくなっている

テスト終盤でも傾きが大きいなら、まだ未発見のバグが多い可能性があります。

未解決バグ数

未解決バグ数は、修正されていないバグの残りです。

バグを発見する
→ 未解決バグ数が増える

バグを修正する
→ 未解決バグ数が減る

この線が長期間横ばいなら、修正が進んでいない可能性があります。

未消化テスト項目数

未消化テスト項目数は、まだ実施していないテストの残りです。

テストを実施する
→ 未消化テスト項目数が減る

この線が減っていないなら、テストそのものが進んでいないと判断できます。

このテーマは、基本情報技術者試験のソフトウェア開発管理や品質管理と関係します。公式の出題範囲やシラバスは、IPA：基本情報技術者試験から確認できます。

科目Aでどう出る？

科目Aでは、グラフの形からテスト工程や品質の状態を推測する問題として出ます。

まず、グラフの軸と凡例を確認します。

1. 横軸を見る
   → テスト消化件数か、時間か

2. 縦軸・凡例を見る
   → 累積バグ件数か、未解決バグ数か

3. テスト終盤の変化を見る
   → 横ばいか、急増か、停滞か

累積バグ件数だけが描かれている場合

テスト消化件数を横軸、累積バグ件数を縦軸にしたグラフでは、終盤の傾きを見ます。

終盤の形	判断
横ばいに近づく	新しいバグの検出が減っている
まだ急増している	未発見バグが多く残っている可能性

特に、目標として設定された累積バグ件数に到達していても、終盤で曲線が急に伸びているなら安心できません。

目標件数に到達
＋
終盤でも傾きが大きい
↓
まだバグが見つかり続けている
↓
未発見バグが多い可能性

複数の管理指標が描かれている場合

未消化テスト項目数・未解決バグ数・累積バグ件数などが同時に描かれている場合は、1本だけではなく組み合わせて判断します。

グラフの状態	推測できること
未消化テスト項目数が減る	テストが進んでいる
累積バグ件数が増える	新しいバグが見つかっている
未解決バグ数が減る	バグ修正が進んでいる
未消化テスト項目数が横ばい	テストが進んでいない
未解決バグ数が横ばい	バグ修正が進んでいない
複数の線が長く横ばい	工程全体が停滞している可能性

つまり、

「バグが増えていない」だけでは、品質が良いとは判断できない

ということです。

テストそのものが止まっていれば、新しいバグが見つからないのは当然だからです。

どんな場面で使う？

バグ管理図は、テスト工程の進捗と品質を同時に確認したい場面で使います。

テスト項目が予定どおり消化されているか確認する
バグの検出ペースが落ち着いてきたか確認する
未解決バグが減っているか確認する
テスト工程が停滞していないか確認する
リリース判断の材料にする

ただし、バグ管理図だけで品質を完全に判断するわけではありません。

実際には、

重大なバグが残っていないか
必要なテストケースを消化したか
要求事項を十分に確認できたか
修正後の再テストが完了しているか

なども合わせて確認します。

テストの種類そのものを整理したい場合は、ソフトウェアテストの種類とは？も確認すると、単体・結合・システム・負荷・退行テストとの関係がつかみやすくなります。

よくある誤解・混同

誤解1：目標バグ件数に達したらテスト完了

誤りです。

目標値は管理上の目安であり、到達しただけで品質が十分とは限りません。

テスト終盤でも累積バグ件数が急増しているなら、まだ未発見のバグが多い可能性があります。

誤解2：累積バグ件数が多いほど品質が悪い

単純には判断できません。

多くのテストを実施した結果、多くのバグを発見できた場合もあります。

重要なのは、テストの進行状況と合わせて、いつ・どの程度のペースでバグが見つかっているかを見ることです。

誤解3：累積バグ曲線が右肩上がりなら異常

累積件数なので、バグが見つかれば曲線は増えていきます。

見るべきなのは「増えているか」ではなく、終盤でも増え方が大きいかです。

誤解4：バグ検出数が横ばいなら品質が安定した

必ずしもそうではありません。

未消化テスト項目数も横ばいなら、テストそのものが進んでいない可能性があります。

バグ検出数が横ばい
＋
未消化テスト項目数も横ばい
→ テスト停止の可能性

誤解5：ゴンペルツ曲線と完全に同じもの

ゴンペルツ曲線は、テストの進行と累積バグ検出の関係をS字型の曲線として捉え、バグ検出の収束傾向を見るときに使われます。

バグ管理図では、累積バグ件数だけでなく、未解決バグ数や未消化テスト項目数など、複数の管理指標を扱うこともあります。

比較	バグ管理図	ゴンペルツ曲線
主な目的	テスト進捗とバグ状況の管理	バグ検出の収束傾向を見る
見るもの	累積バグ件数、未解決バグ、テスト進捗など	累積バグ検出のS字型変化
判断の中心	傾き・増減・停滞	曲線の立ち上がりと収束

今回のように「テスト終盤でも累積バグ曲線が急増しているか」を読む問題では、ゴンペルツ曲線の収束イメージも理解していると判断しやすくなります。

確認問題（基本情報技術者試験対策）

テスト消化件数を横軸、累積バグ件数を縦軸にしたグラフがある。テスト項目の大部分を消化した時点でも、累積バグ件数の曲線の傾きが大きくなっている。この状況の説明として最も適切なものはどれか。

ア. テストが十分に収束し、品質が安定している
イ. まだ多くのバグが内在している可能性がある
ウ. バグ累積件数が多いので、必ずテストケースが不足している
エ. 累積件数が増えたので、修正済みバグが再発している

▶ クリックして答えと解説を見る（ここを開く）

正解：イ

テスト終盤でも曲線の傾きが大きいということは、新しいバグがまだ多く見つかっている状態です。

そのため、未発見のバグがまだ多く残っている可能性があります。

👉 判断ポイント
終盤で横ばい → 安定傾向、終盤でも急増 → 未発見バグを疑う

まとめ（試験直前用）

バグ管理図は、テスト進捗とバグの状態を合わせて見る
累積バグ件数は総数より終盤の傾きを見る
終盤で横ばいに近づく → 新規バグが減っている
終盤でも急増 → 未発見バグが多い可能性
未消化テスト・未解決バグが横ばい → 工程停滞を疑う
目標バグ件数に達しただけでは、テスト完了や品質の良さは判断できない

総数だけで安心しない。終盤の傾きとテスト進捗を一緒に見る。

🔗 関連記事

🏠 基本情報技術者トップに戻る