図4 テスト設計で実施する作業の流れ
図4 テスト設計で実施する作業の流れ
[画像のクリックで拡大表示]
図5 全体テスト計画に記載すべき項目例<BR>全体テスト計画は,プロジェクト開始時に作成してユーザーやプロジェクト・メンバーと共有する
図5 全体テスト計画に記載すべき項目例<BR>全体テスト計画は,プロジェクト開始時に作成してユーザーやプロジェクト・メンバーと共有する
[画像のクリックで拡大表示]
図6 信頼度成長曲線&lt;BR&gt;累積バグ量を示した曲線は,時間の経過とともに徐々になだらかになっていく。&lt;BR&gt;
図6 信頼度成長曲線<BR>累積バグ量を示した曲線は,時間の経過とともに徐々になだらかになっていく。<BR>
[画像のクリックで拡大表示]

テストにも「設計」が必要

 実際にテストを実施する際には,プログラム開発と同様に,テストの「設計」が必要になる。しっかりした設計を行わずにテストを実施したのでは,テスト手法を十分に活用できない。プログラミングを覚えたてのプログラマが,いきなりコーディングを始めるようなものだ。では,テスト設計とはどのようなものなのだろうか。

 図4[拡大表示]に,テスト設計で実施する作業を示した。図に示すように,テスト設計ではまず,テスト対象となるモジュールやシステムの特性,仕様を考慮したうえで,適切なテスト手法やテスト・ツールを選択する。

 次に,具体的に何をテストするのか,というテストの内容を決める。この際,バグがなかった場合にどんな結果が期待できるのかを表す期待結果を定義することが重要である。当然のことだがこれを定義しないと,せっかくテストを実施しても,バグに気付くことはできない。

 テストの内容と期待結果の組み合わせのことを「テスト項目(Test Item)」と呼ぶ。テスト項目は,テストの論理的な最小単位である。

 すべてのテスト項目を定義したら,各テスト項目を確認するために,テスト実施の手順とテストで利用するデータ(テストデータ)を決定する。テストの手順とテストデータを組み合わせたものを「テストケース」と呼ぶ。テストケースは,テストを実行する最小単位であり,通常は1つのテストケースで,1つ以上のテスト項目を確認する。

 テストケースのまとめ方が悪いと,同じテスト項目を何度もテストする羽目になる。それを防ぐためには,テストケースとテスト項目の対応関係を明確にしておき,テスト項目のダブリや漏れをなくすようにしたい。そのうえで,最小限のテストケースで,より多くのテスト項目を網羅できるように,テストケースを作成することが大切である。

テストの計画を立案する

 冒頭で,テストは段階的かつ計画的に実施しなければならない,と述べた。そこで極めて重要になるのが,具体的にどのような段階を踏んでテストを実施するのかを決める「テスト計画」である。

 テスト計画には,「全体テスト計画」と「フェーズ別テスト計画」がある。

 全体テスト計画は,テスト・プロセス全体の計画を立案するもので,プロジェクト計画作成時に開発計画と同時に作成する。

 具体的には,テストを実施するための人員配置やテスト環境の手配などテストに必要な資源を明確にし,そのうえで各テスト・フェーズの位置付けや品質目標,各テスト・フェーズの終了基準,管理すべきポイントなどを定義し,ユーザーやプロジェクト・メンバー間で共有する(図5[拡大表示])。特にテスト・フェーズの終了基準は重要だ。次のフェーズに進むための最低条件をあらかじめ定義しておくことで,スケジュール遅延により不十分な品質のまま次フェーズに進んでしまうことを避けられるほか,各フェーズの目標と管理のポイントも明確になる。

 全体テスト計画は,システム開発プロジェクトのテスト・プロセス全体を定義する非常に重要な役割を担う。ここで定義したステップに基づいて,すべてのテストが実施される注3)

 一方のフェーズ別テスト計画は,全体テスト計画で定義された各テスト・フェーズごとのテストの進め方やテストの実施内容を詳細に定義するもので,各テスト・フェーズの実施前に作成しておく。

 具体的には,テスト・フェーズの基本目標や終了基準,テスト資源に基づいて,テスト方針やテスト内容の概要,テスト準備の作業内容と方法,具体的な品質目標,管理のポイントと管理方法などを記述する。ここで定義したテスト内容の概要は先述したテスト設計のベースになり,管理のポイントと管理方法は,テスト・フェーズを管理するベースとなる。

進ちょく,バグ,品質を管理する

 最後に,プロジェクト・マネジャーやリーダーによるテスト管理の方法について説明しておこう。

 テスト管理では,上で述べた「全体テスト計画」と「フェーズ別テスト計画」で定義されたテストの品質目標がどこまで達成されているかを把握し,それを効率的に達成するための方法や問題への対策を検討する。

 このためには,テストの進行状況や目標の達成状況を定量的に把握する必要がある。具体的には,テストの状況を次の3つの観点で計測する。

(1)進ちょく管理

 テストを「予定したテストケースやテスト項目の消化作業」と考えて,作業の遅延や停滞,作業上の問題点などを管理する。特にシステムの動作を保証するためのテストが増えるテスト後半では,この進ちょく管理がメインになる。

(2)問題状況の管理

 テストを「バグを発見する作業」と考え,バグを発見する効率や発見したバグ量などを管理するとともに,対策状況を把握する。

 例えば,発見したバグ量の管理には「信頼度成長曲線」を利用する(図6[拡大表示])。信頼度成長曲線は通常,曲線の傾きが徐々になだらかになっていく。この傾き具合によって,品質が安定していることを確認する。

 テスト・チームは,バグを発見することはできても修正することはできない。しかし,プロジェクト・マネジャーやリーダーがバグ修正の進み具合を把握し,バグ発見と修正のバランスをうまく調整することで,効率的にテストを実施できる。

(3)品質水準の管理

 テストを「計画された品質目標を達成する作業」と考え,その時点の品質目標の達成度や問題解決状況などに基づいて,テストの終了判定や次フェーズへの品質状況の引き継ぎを行う。特にフェーズ終了基準をどの程度満たしているのかを重点的に把握し,早期に終了基準を満たすための具体的な対策を講じる。


石川 和則/エス・キュー・シー 取締役

東海大学海洋学部卒業。1984年にCSK入社。OS/2関連のテスト・プロジェクトなどに参加。その後,エー・アンド・アイシステムでアプリケーション開発などに従事した後,1995年よりエス・キュー・シー取締役に就任。現在は上海の現地法人である索科思軟件測試の副董事長も兼務

出典:日経ITプロフェッショナル 2004年6月号 46ページより
記事は執筆時の情報に基づいており、現在では異なる場合があります。