« TestLinkのベストプラクティス集 | トップページ | astah* professional 6.1の要求図 »

2010/02/28

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

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

【元ネタ】
山浦恒央の“くみこみ”な話(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版 - ヤル気こそプロジェクト成功の鍵」の翻訳者の方でもある。
他記事もとても参考になるので、読んで欲しいと思う。

|

« TestLinkのベストプラクティス集 | トップページ | astah* professional 6.1の要求図 »

TestLink」カテゴリの記事

ソフトウェア工学」カテゴリの記事

コメント

こんにちは。

@ITの記事はやや読みづらかったですが、ふむふむと思いました。

僕のこれまでのテスター経験から言うと、グラフでは、タイプが複合していることが、ありますね。

2・停滞型 + 5・お祭り型は、あります。 

2・停滞型 + 6・バグだらけ型 あります。

まだまだ、組み合わせは他にもあると思います。

グラフにすると、最初はモデル通りですが曲線の動きがあるとこから、ぎゅんと
加速度的なカーブ(別モデルに切り替わる)を描いたり、もっとも、強いパターン
(ボトルネック)が現れたグラフになるといったとこでしょうか。

# 最初は、八朔さんの会社に預けられて
テスターとして新人時代をすごしましたo(*^▽^*)o

その経験は、今もソフト開発に役だっていると思います。

投稿: YF | 2010/02/28 22:39

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/47685762

この記事へのトラックバック一覧です: テスト消化曲線とバグ発生曲線のパターン診断:

« TestLinkのベストプラクティス集 | トップページ | astah* professional 6.1の要求図 »