テスト項目の設定では,テスト対象におけるテスト項目の網羅性が重要となる。「テスト項目を漏れなく洗い出すには,設計カバレッジによるテスト項目の確認が必要」。こう話すのは,豆蔵の大西建児氏(ES事業部 シニアコンサルタント)だ。

 設計カバレッジとは,設計すべきテスト項目を設計したかという網羅性を確認するもの。これに対して実行すべきテスト項目をどれだけ実行したかを示す「実行カバレッジ」もある。

 通常,実行カバレッジによる網羅性の確認を取り入れないことはない。テスト項目の一覧を一つひとつ実施していけば,実行カバレッジを確認できる。

 だが,設計カバレッジを確認している現場は意外に少ないようだ。その理由は,「設計カバレッジ」という考え方や具体的な確認方法が,開発現場に定着していないからである。

三つの方法で網羅性を確認

 では,設計カバレッジをどのように確認するのか。豆蔵の大西氏は,具体的な方法として,「リスト網羅」「マトリクス網羅」「グラフ網羅」――の三つを挙げる(図1)。

図1●テスト対象におけるテスト項目の網羅性を確認する三つの方法
図1●テスト対象におけるテスト項目の網羅性を確認する三つの方法
豆蔵の大西建児氏が推奨する「リスト網羅」「マトリクス網羅」「グラフ網羅」の例。それぞれ機能一覧の網羅,2項目の組み合わせの網羅,順序のある処理の網羅――を確認する場合に使う
[画像のクリックで拡大表示]

 これら三つは,いずれも仕様書や設計書などのドキュメントを基に,テスト項目を漏れなく洗い出す方法だ。具体的には,テスト対象の特徴やドキュメントの種類に応じて,適宜,使い分けることになる。

 例えば,最もシンプルなリスト網羅は,「新規会員登録」や「会員情報照会」といった,テスト対象の機能の一覧をリストアップしたものだ。機能一覧表などの機能要件を転記していけばよい。これにより,機能要件に対する網羅性を確認できる。

 マトリクス網羅は,二つの項目の網羅を確認する方法だ。例えば,ブラウザとOSの関係といった環境の組み合わせや,入力フィールドと入力データ,画面と操作といった画面入力の組み合わせなどがある。また,データと条件の組み合わせ,機能と条件の組み合わせなどにも適用できる。

 マトリクス網羅で参照すべきドキュメントには,問題を解決するための条件と行動を表形式で示した「デシジョン・テーブル」や,データの生成・参照・更新・削除を表形式で示した「CRUD図」などがある。

 最後のグラフ網羅は,順番がある項目に対する網羅性を確認する方法だ。例えば,IDとパスワードを入力し,認証後,会員情報を表示する,という処理があるとしよう。この場合,グラフ網羅では,それぞれの「処理」か「流れ」のどちらかに着目する。図1下の例では,処理を表す丸の部分をすべて網羅しているか,あるいは矢印の部分をすべて網羅しているかを確認する。グラフ網羅で参照すべきドキュメントには,フローチャートや状態遷移図,シーケンス図――などがある。

 石川島播磨重工業のシステム子会社であるIHIエスキューブの岸宗俊氏(ソリューション事業部 第三プロジェクトグループ)はリスト網羅を拡張させた「インベントリ」と呼ぶ表を使い,設計カバレッジを確認している(図2)。

図2●機能一覧とテスト項目の組み合わせを確認するインベントリの例
図2●機能一覧とテスト項目の組み合わせを確認するインベントリの例
機能一覧の網羅とともに機能とテスト項目の組み合わせを確認するには,縦軸に機能,横軸にテスト項目を取る「インベントリ」と呼ぶ方法を使うとよい。IHIエスキューブの岸宗俊氏は,縦軸に画面遷移,横軸にそれに対するテスト項目を設定し,テスト対象における網羅性を確認した
[画像のクリックで拡大表示]

 ここで言うインベントリとは,縦軸に機能,横軸にテスト項目を取った二次元の表のこと。基本的にはリスト網羅と同じく機能一覧の網羅性を見るものだが,機能とテスト項目の組み合わせを明確にした点が異なる。これにより,機能の網羅性を確認するとともに,各機能に対してどんなテストを実施するかというテスト内容の網羅性も確認できるようにした。岸氏の場合,要件定義書や基本設計書に記載された画面遷移を縦軸に,各画面遷移に対する具体的なテスト項目を横軸とした。

 「設計カバレッジを確認するには,要件から仕様,テスト項目,テストケースまでをツールで一元管理することも大事」。こう話すのは,日立ハイテクソリューションズの佐藤氏である。佐藤氏は,自社のパッケージ・ソフトの要件や仕様,テスト項目,テストケースなどを管理するため,日本テレロジックの要件管理ツール「DOORS」とマーキュリー・インタラクティブ・ジャパンのテスト管理ツール「Test Director」を導入。現在,パッケージ・ソフトの機能要件やシステム仕様などをDOORSに登録中だ。将来的には,Test Directorで管理するテスト項目やテストケースと,登録した情報をひも付ける。「パッケージ導入時には,顧客ごとのカスタマイズも発生する。それを含めて一元管理すれば,仕様変更による影響範囲を追跡できるようになり,テストの漏れを少なくできる」(佐藤氏)と期待を寄せる。