テスト消化曲線とバグ発生曲線のパターン診断
テスト消化とバグ発生曲線(バグ収束曲線)をパターン分けした素晴らしい記事があったのでメモ。
【元ネタ】
山浦恒央の“くみこみ”な話(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版 - ヤル気こそプロジェクト成功の鍵」の翻訳者の方でもある。
他記事もとても参考になるので、読んで欲しいと思う。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
- 組合せテストにおける因子と水準はどちらを最優先で考えるべきか(2022.12.04)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
「TestLink」カテゴリの記事
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- TestRailの感想(2021.06.23)
コメント
こんにちは。
@ITの記事はやや読みづらかったですが、ふむふむと思いました。
僕のこれまでのテスター経験から言うと、グラフでは、タイプが複合していることが、ありますね。
2・停滞型 + 5・お祭り型は、あります。
2・停滞型 + 6・バグだらけ型 あります。
まだまだ、組み合わせは他にもあると思います。
グラフにすると、最初はモデル通りですが曲線の動きがあるとこから、ぎゅんと
加速度的なカーブ(別モデルに切り替わる)を描いたり、もっとも、強いパターン
(ボトルネック)が現れたグラフになるといったとこでしょうか。
# 最初は、八朔さんの会社に預けられて
テスターとして新人時代をすごしましたo(*^▽^*)o
その経験は、今もソフト開発に役だっていると思います。
投稿: YF | 2010/02/28 22:39