ソフトウェア開発やシステム開発のテスト活動を行っている際に、こんな不安を感じたことはありませんか？
「テストの進捗が悪い気がする…、このまま進めて納期に間に合うのか？」
「このシステムはバグが多い気がする…、このまま進めて品質は大丈夫なのか？」
「バグが全然出ない…、このテスト内容は本当に大丈夫なのか？」
納期の不安、品質の不安、テスト項目の不安など、これらの不安を何のヒントも無しに払拭するのは難しいですよね。
このようなテスト活動における不安を払拭し、問題の早期発見の助けとなるものがバグ管理図になります。
本記事では、テスト活動のモニタリングの際に役立つ「バグ管理図」の概要、構成、メリットについて解説します。
バグ管理図とは
バグ管理図は「テスト項目数」と「バグの数」を時系列で示したグラフになります。
具体的には下図のような折れ線グラフになります。
ソフトウェア開発やシステム開発におけるテスト活動の進捗や状況を確認するために活用するグラフになります。
バグ管理図は主にテスト活動の状況をモニタリングするために活用しますが、テスト活動の進捗が視覚的にもわかりやすくなっているため、お客様や関係者に作業の進捗を共有する際にも使用できる便利なグラフとなっています。
バグ管理図の構成
バグ管理図の構成は下記の通りとなります。
バグ管理図の縦軸と横軸
- 縦軸
テスト項目数、バグ数 - 横軸
時間（テスト開始日からの経過日数）
バグ管理図の折れ線
- テスト消化予定
テスト消化予定の推移。
テスト項目は日々消化されていくため、右下がりのグラフになる。
グラフの数値には過去のテスト結果やテストマネージャーの経験による数値を反映する。 - テスト消化実績
テスト消化実績の推移。
テスト消化実績にはテストに合格した項目の数を反映するため、不合格の場合はカウントしない。
「テスト消化予定」と同様で、テスト項目は日々消化されていくため、右下がりのグラフになる。 - バグ検出推定
バグ検出数推定の推移。
テストの実施によってバグは日々検出されるため、右上がりのグラフになる。
グラフの数値には過去のテスト結果やテストマネージャーの経験による数値を反映する。 - バグ検出実績
バグ検出の実績数。
バグ検出の累計数をカウントするため、検出したバグが解消しても実績数はマイナスしない。
「バグ検出推定」と同様で、テストの実施によってバグは日々検出されるため、右上がりのグラフになる。 - 未解決バグ
未解決バグの検出数。
日々の未解決バグの数をカウントする。
未解決バグは解消することがあるため、他の線と違って数値が増えたり減ったりする。
バグ管理図のメリット
バグ管理図はテスト活動が想定通りに進んでいるか否かを判断する材料の一つとなります。
テスト活動の進捗が一目でわかるため、関係者にとって有意義な情報となります。
バグ管理図はテスト活動の進捗確認に役立ちますが、役割はそれだけではありません。
進捗確認以外にも、テスト活動における様々な問題に気づくキッカケを与えてくれることがあります。
具体的には、バグ管理図を見ることで下記のような問題に気づく場合があります。
- テスト実施者の問題
- テスト実施上の重大な問題
- テスト項目の品質問題
- 前工程の品質問題
どういった場合に上記のような問題に気づくことができるのか、実際にバグ管理図を見ながら解説します。
テスト実施者の問題への気づき
上図は毎日テストを消化してバグも検出できていますが、想定よりもテスト消化実績とバグ検出数が少ないです。
未解決バグ数については検出した後に解消できているので、テストが止まっている訳ではなさそうです。
テストは実施できているのに作業が遅い原因としては、下記のようなことが考えられます。
- テスト実施者が作業に集中できない何かがある（別件作業をしながら進めているなど）
- テスト実施者が新人で手間取っている
このように、バグ管理図の状態を見ることでテスト実施者に何かしらの問題が発生していることに気づくことができます。
テスト実施上の重大な問題への気づき
上図は途中まで順調にテストを消化していましたが、途中からテスト消化数、バグ検出数、未解決バグ数が停滞してしまいました。
本件の原因としては、下記のようなことが考えられます。
- テスト実施中に重大なバグに直面し、テスト活動が停滞している
テスト消化数、バグ検出数、未解決バグ数のすべてが止まっている場合は、解決しないバグに直面して以降のテストが実施できない状態に陥っている可能性が高いです。
テスト項目の品質問題への気づき
上図はテスト消化が想定よりも早く、バグ検出数が少ないため、優秀なテスト活動が実施できているように思えます。
この場合、本当に優秀なテスト活動が実施できている場合もありますが、下記のような問題が発生している場合もあります。
- テスト項目の品質が悪く、バグが検出できていない
テスト消化の進みが早いことは、順調なテストができていることとイコールにはなりません。
仮に上記のような問題が発覚した場合には、テスト項目の見直しが必要となり、内容次第ではテスト設計からやり直すこともあります。
前工程の品質問題への気づき
上図はテスト消化数が予定よりも少ないですが、バグ検出数は多く出ています。
この場合、テストの実施は進んでいるのですが、バグが多すぎてテストが消化できていないことが考えられます。
上記を考慮すると、本件の原因としては下記のようなことが考えられます。
- 前工程の時点で品質が悪い
そもそもの問題として、前の工程で十分なテストができていないため、現状の工程で多くのバグが発生していることが考えられます。
このパターンの場合は、前の工程に戻って再度テストを実施する場合もあります。
まとめ
バグ管理図の概要は下記の通りとなります。
- バグ管理図は「テスト項目数」と「バグの数」を時系列で示したグラフである
- バグ管理図は主にテスト状況をモニタリングする際に活用する
- グラフの状態によって早期に問題点を見つけることができる
テスト活動をテスト実施者の感覚で進めてしまうと、スケジュールの遅延やテスト活動そのものの問題点に気づけない場合があります。
バグ管理図を活用することで、テスト実施者の感覚ではなく客観的なデータとして進捗状況を確認することができ、グラフの状態によって問題を早期に発見できる場合もありますので、バグ管理図はテスト活動を行う際には作っておきたい資料の一つになります。
