品質のトラッキング/コントロールで大きな役割を果たすのはテスト・フェーズである。このフェーズを効率的に実施するためには,しっかりとした「テスト計画」を 立案しておく必要がある。特に,テストの開始・完了基準をきちんと計画しておくことは,テストの進ちょくやコスト管理の観点からもきわめて重要だ。

布川 薫/日本IBM

 前回に引き続き,プロジェクト遂行段階における品質のトラッキング/コントロールに関する具体的な手段について話を進める。今回は,プロジェクトの計画段階で作成した「品質管理計画書」(第3回参照)を基に策定する「テスト計画」について,日本IBMの手順に沿って解説していこう。

 テスト計画の立案では,プロジェクト終了までの品質管理の方針を記述する「テスト方針書」(Comprehensive Test Plan)をまず作成する。テスト方針書はテスト・フェーズ全体のマスタープランとなるもので,プロジェクトで作成する様々な計画の中でも,特に重要な計画の1つだ。

 図1に,日本IBMにおけるテスト方針書の作成手順を示す。図に示すように,テスト方針書はプロジェクトの基本計画や要件定義書,外部仕様書,品質管理計画書の情報を見ながら,プロジェクト・マネジャー自身が責任を持って作成する。

図1●テスト方針書の作成手順(DFDで記述)
図1●テスト方針書の作成手順(DFDで記述)

 テスト方針の検討は,プロジェクトの品質管理計画の一部として要件定義フェーズの段階から開始する。その上で,最初のテスト・フェーズである単体テスト・フェーズの開始前,より具体的に言えば内部設計フェーズの中程までに,テスト方針書を作成しておくのが望ましい。作成したテスト方針書は,しっかりと検査し,内部設計の完了時点で公式レビューにかけておく。

 テスト方針書には,テスト・フェーズ全体の構成,各テストの位置付けや目的,テスト方法,テストの開始・完了基準,テストケース(何をテストするかを定めたもの)の定義方法,テストツールと使用データ,テストのスケジュール,テストを実施する組織計画――などを記述しておく。

 プロジェクトには,要員,スキル,コスト,スケジュールの面で様々な制約があるため,与えられた制約の範囲内で最も有効な方針を立てる必要があるのは言うまでもない。限られたスケジュールとリソースでテストを効率良く行うためには,パフォーマンスやセキュリティ,信頼性といった最もクリティカルな要件や機能,すなわち「フォーカス・エリア」について重点的にテストを実施する計画を立てるべきである。

方針に従い詳細な計画を立案

 テスト方針書を作成したら,それに基づいて,テスト・フェーズごとのより詳細なテスト計画書を立案していくことになる。具体的には,単体テスト計画書やコンポーネント間統合テスト(統合テストa)計画書,サブシステム間統合テスト(統合テストb)計画書,システム・テスト計画書などを作成する(図2)。プロジェクト・マネジャーが作成するテスト方針書とは異なり,テスト・フェーズごとのテスト計画書は通常,開発リーダーが作成する。

図2●テスト計画の全体構成
図2●テスト計画の全体構成
[画像のクリックで拡大表示]

 単体テスト計画書は,テスト方針書が完成したら速やかに作成し,内部設計フェーズの完了時点で公式レビューにかける。単体テスト計画書に基づいて,開発担当者が単体テスト仕様書を作成,それに基づいて単体テストを実施するからだ。

 統合テスト計画書とシステム・テスト計画書は,対応するフェーズの仕様書や完了基準(統合テストなら外部設計フェーズ,システム・テストなら要件定義フェーズ,第3回参照),稼働開始基準を参照しながら,それぞれのテストを開始する前に十分な余裕をもって作っておく。単体テスト計画書や統合テスト計画書,システム・テスト計画書の作成時期は,プロジェクト期間やテスト機器の導入準備期間によっては,さらに早くなることがある点に注意していただきたい。

 ただし,プロトタイピングを活用したRAD(Rapid Application Development)型のクライアント/サーバー・システム開発や,イタラティブ(繰返し型)な開発工程をとるオブジェクト指向開発,Webシステム開発では,外部設計の早い段階から開発と同時並行的にテストを実施するのが普通である。このようなケースでは,開発とテストを開始する前,すなわち設計の開始時点までにテスト環境の準備も含めてテスト方針書とテスト計画書を作っておかなければならない。

テスト方法を入念に決める

 次に,テスト計画書に記述する内容について解説しよう。テスト計画書には,テスト方針書で記述した各項目をブレークダウンする形で,テストフェーズごとの詳細な計画を記述する。具体的には,「テストの目的と範囲」,「テスト方法」,「テストの開始基準・完了基準」,「テスト資源と体制」,「スケジュール」,「検収方法」といった各項目について詳細な計画を記入する。

 「テストの目的と範囲」は,そのテスト・フェーズの目的とテスト範囲を決めるものである。具体的には,欠陥除去工程全体の中での位置付けと範囲,テストケースの目的や性格,構成などを決める。

 「テスト方法」は,使用するテストツールやテスト用のデータベース環境の構成方法,テストツールの使用方法,テストケースの定義方法,テストケース番号の採番方法,テスト・シナリオの組み方,テストデータの作成方法や保管方法,テスト実行結果の記録方法や結果の検証方法,デバッグ方法や欠陥の管理方法――といったテスト方法に関する計画を記述する項目だ。

 ここで,テストケース番号の採番とは,テストケースにカテゴリーごとに番号を振ることである。テスト計画書で定義したテストケースの採番方法やテストケースの定義方法に従って,テストケースの内容を「テストケース定義フォーム」に記入。これを実行の連続性を考慮して何枚かにまとめたものが「テスト・シナリオ」となる。図3に日本IBMで使われているテストケース定義フォームの例を示す。この例では,テストケース番号はコンポーネントの識別コード,ケースのカテゴリー・コード,およびカテゴリーごとのシークエンス番号から構成されている。このテスト・シナリオに沿って実際のテストが実施されることになる。

図3●テストケース定義フォームの例
図3●テストケース定義フォームの例
[画像のクリックで拡大表示]

この先は会員の登録が必要です。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら