テスト消化曲線とバグ発生曲線のパターン診断

テスト消化とバグ発生曲線(バグ収束曲線)をパターン分けした素晴らしい記事があったのでメモ。

【元ネタ】
山浦恒央の“くみこみ”な話（16）：テスト消化曲線とバグ発生曲線の7パターン診断 - MONOist（モノイスト）

テスト消化曲線は、未実施テストケース数を時系列に表示したグラフで、普通は右肩下がりになる。
バグ発生曲線(バグ収束曲線)、累積バグ数を時系列に表示したグラフで、普通は右肩上がりになる。

テスト消化とバグ発生曲線は密接に関係している。
理由は、ブロッキングバグがたくさん出るほど、ブロックするテストケースが増えてしまってテストの進捗は遅れるからだ。

実際にTestLinkでテスト管理してみると、ブロッキングバグが出るたびに、テストに失敗するだけでなく、ブロックするテストケースも増える。
例えば、テストに1回失敗すると、10個ぐらいのテストケースはテスト不能になってしまう。

僕の経験では、TestLinkでアジャイル開発っぽくテスト計画を実施すると、テスト計画にはせいぜい500個ぐらいのテストケース数なのに、50件もバグを見つけたら、1ヶ月で全てのバグを潰すのはほぼ絶望的になる。
つまり、全テストケースの10％も失敗したら、殆どテスト不能になってしまい、テストしても無意味になってしまう。
結局、見つけたブロッキングバグをひたすら修正するのが一番の早道だ。

テスト消化曲線とバグ発生曲線の7パターン診断 － ＠IT MONOistでは、下記の7パターンに分類しているのが参考になる。
自分の経験と合わせて書いてみる。

1・理想型

→「消化したテスト項目数」と「摘出したバグの数」の実測値が予定の曲線に合致している場合。
　テストが計画通りに進んでいるパターン。
　普通のプロジェクトでは少ないだろう。

2・停滞型：テスト担当者の能力不足

→テストの進捗も遅れているが、バグも少ない場合。
　例えば、テスターが新人やヘルプで、テストの経験が少なかったり、システムの仕様を知らなかったりする場合が多い。
　普通のプロジェクトでは、業務に詳しい人を投入して、テストもバグ発見もはかどらせるようにする。

3・疑似高品質型：本当にプログラムの品質が良いか？

→テストの進捗は早く進んでいるが、発見したバグが少ない場合。
　いわゆるメトリクスの罠に陥っている時が多い。
　本当にバグが少なくて高品質なのか、あるいは、テスターの能力が低いのか、見極める必要がある。

4・真正高品質型：プログラムの品質が良い

→テストの進捗が計画通り、又は早く進んでいるが、摘出バグが予測よりも少ない場合。
　プログラムの品質が良い場合が多い。
　このパターンに当てはまれば、システムテスト工程になっても、毎日定時退社できる幸せなプロジェクト(笑)

5・お祭り型：ベテランの急ぎ仕事

→テストの進捗は早いけれど、摘出バグも多い場合。
　いわゆる「派手なお祭り状態」のパターン。
　バグが多いのにテストがはかどっている状態を類推すると、致命的なブロッキングバグは少なくて、すぐにバグを修正できているのだろう。
　つまり、バグは単純な原因が多いのだろうと推測される。
　熟練プログラマが急いで作ると、このパターンになるらしい。
　戦略としては、バグを傾向分析して、同種バグを徹底的に潰せば良い。

6・バグだらけ型：最も普通のパターン

→テスト進捗は予定通りだが、摘出バグがはるかに多い場合。
　普通のプロジェクトで最も多いパターン。
　テストケースの品質は普通で問題ないが、プログラムの品質が悪い典型的なパターンと言えるだろう。
　現場リーダーは、テスト工程がこのパターンに陥るのを普通は予測しているので、残業して休日出勤すれば間に合うだろう、と思ったりもする(笑)
　上記パターンと同様に、ブロッキングバグが出てブロックしたテストケースも多く出ているものの、確実にバグ修正できているから、今のペースで頑張ればいい。
　同種バグを潰す戦略が徹底できれば、システムの品質は上がってくるはず。

7・深刻型：前フェイズの品質が低い

→テスト消化数が少なく、テストは遅れているのに、摘出バグが予想通り、又ははるかに多い場合。
　ブロッキングバグが多発して、テスト不能な状態になりがちで、テストがはかどらない状況になっている。
　典型的なデスマーチ・プロジェクト。
　
　上記の記事では二つの戦略があると言う。
　一つは、「品質の悪いソース・コードをだましだまし使う」。
　納期目前でソースを捨て去ることはできないので、ソースへパッチを継ぎ接ぎしながら、テストをこなしていく戦略。
　普通のプロジェクトではよく見られるやり方で、最後は徹夜で残業して納めることになる。
　
　他方は、「すべてのソース・コードを捨て、設計し直す」。
　これが本来の正当な戦略なのだろう。実際一から作り直した方が早く作れて早くテストできる時が多い。
　この戦略を実行できるには、ソースのインターフェイスが間違っていないのが前提条件。
　インターフェイスは変えないが、中身のロジックは全て作り直せば、他プログラムに影響はしない。

TestLinkを運用すると、テスト実績はTestLinkCnvMacroで簡単にメトリクス分析できるし、バグ情報はRedmineなどのBTSに溜まっているので、いくらでも計測できる。
PerlやRubyなどのスクリプト言語を使えるなら、直接DBから検索して出力すればいい。

上記の記事を書かれた山浦さんは、ソフトウェアテストの専門家の方であり、「ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵」の翻訳者の方でもある。
他記事もとても参考になるので、読んで欲しいと思う。