基礎から学ぶソフトウエア・テスト
基礎から学ぶソフトウエア・テスト（6）テストのマネージメントとレポート（前回からの続き） テスト結果の分析/報告にはグラフを駆使しようさて，ここまでテスト結果の適切な報告が品質向上に重要だと繰り返し説明してきました。では具体的にどのようにレポートすればいいでしょうか？ ダラダラと文章ばかり書いても開発者やマネージャは読んでくれないかもしれません。 そこで最後に，ソフトウエア・テストが情報サービスとして有益な情報を流すためのメトリクス（指標）の例ををいくつか紹介しましょう。 品質把握：リリースのための判断材料の提供
品質を把握するためのグラフとしては，図5[拡大表示]のようなバグのオープン・クローズ・チャートが挙げられます。バグ検出数，未対応バグ数，対応バグ数の累計と，テスト・ケースの残数（実施件数）を時系列に折れ線グラフにしたものです。 このグラフからは多くのことが読み取れます。まず，バグ・レポートで指摘したバグが，どこまで対応されているのかがわかります。バグが直っていなければ納品はできませんから，とても重要な判断材料となります。また，バグの累計数の曲線がなだらかになっていくことでバグの発生が収束し，品質が安定していることを確認できます＊9。 また，テスト・ケースの残数を同じグラフ内に別軸でグラフにすることで，テストの進ちょく状況も把握できます。バグの曲線がなだらかになっていても，テストの残数が減っていかない場合は，ただテストをしていないだけで，バグが収束したとはいえません＊10。このようにバグの件数とテストの残数を一緒に見ることで，バグの収束状況をより正確に把握することができるわけです。 また，図6[拡大表示]のような回帰分析の計算値によってバグ検出件数を予測する方法もあります＊11。ただ，これだけで品質がいい，悪いを決めつけるのはよくありません。あくまで判断材料の一つであり，テストを実施するなかで気付いた具体的なバグの状況やテスト実施の状況を加味して判断するのがよいでしょう。 原因分析：今後の改善のための材料の提供開発力を向上させるための情報としては，図7[拡大表示]の工程別の原因種類グラフを作成するのが有効です。要件定義，設計，コーディングのどの工程で何が原因で混入したバグが多いか，その傾向をつかむことができます。 図の見方を説明しましょう。凡例の「過剰」というのは，勝手な解釈で仕様を決めてしまい追加した機能のことです。設計やコーディングの工程で多いことがわかります。「欠如」は，考慮されていない機能，漏れている機能です。これは圧倒的に要件定義の段階で多く発生していますね。「理解不足」は，スキル不足，環境/ツールについての調査不足など知識が足りないこと，「単純ミス」は，文字通りタイプミスや記述ミス，「手順ミス」は，構成管理やデータ作成の失敗などです。工程が進むにつれて，理解不足や単純ミスが原因となるバグが増えていくこともわかるでしょう。 テストの効果を把握するための指標としては，欠陥除去効率（Defect Removal Efficiency）という指標があります（図8[拡大表示]）。納品前と納品後に出たバグ検出件数との合計から，各テストのレベルで見つけることができたバグの割合を算出します。これを，各工程ならびにテスト全体で，どれだけバグを見つけることができたかをグラフにしたものです。この結果から，テストの組み立て方の改善につなげることができるというわけです。DREの計算方法は図9[拡大表示]を参照してください。 DREのグラフを作るには，納品後のバグの状況もきちんと調査する必要があります。そのため，バグの調査を納品後も継続する必要があるという難しさはありますが，テストの効果を見るにはとても役立ちます。調査可能な環境にある方は，ぜひ作成してみてください。
☆ ☆ ☆ さて，6回にわたってソフトウエア・テストの基礎を解説してきましたが，いかがだったでしょうか？ テストは，テスト技術を使って効率良く効果的に行い，開発力向上のための情報サービスとして機能してこそ価値があります。本稿では基礎の部分しか説明できていませんが，最近はソフトウエア・テストに関する書籍，雑誌，シンポジウムなど情報を入手する機会も増えてきています。ぜひ，それらを活用し，ユーザーに喜ばれるソフトウエア作りができるように，開発力を向上させてください！
出典：日経ソフトウエア 2005年9月号
100ページより
（記事は執筆時の情報に基づいており，現在では異なる場合があります）  |
           |
