PR

 実際の作業を説明していこう。テスト範囲の検討では「テストするところ」「テストしないところ」を切り分ける。テスト計画で検討したテスト対象は、業務や機能といった大きな粒度になっている。テストケース作成方針では、より細かい単位まで分解して検討する。実際のテスト内容をイメージできる粒度が目安だ。

 ECサイトを例に取ると、商品管理機能は商品登録機能、商品参照機能、商品更新機能、商品削除機能といった、より小さい粒度の機能に分解できる。さらに小さな粒度への分解も可能だ。商品登録機能をユーザー操作目線で見ると、商品データ入力画面、商品データ入力内容確認画面、商品データ入力完了画面と複数の画面に分けられる(図2)。

図2●商品管理機能を例にしたテスト対象の分解
図2●商品管理機能を例にしたテスト対象の分解
[画像のクリックで拡大表示]

 分解の方法はシステムやプロジェクト、テストレベル、テストタイプで異なる。関係者間での混乱を起こさないよう、分解の単位とその根拠についてきちんと合意形成しておこう。テスト対象を分解したら、それぞれをテスト範囲とするかどうかを検討する。

 テスト観点の検討では、テストで確認すべきことを決める。テスト範囲内にあるテストの対象ごとに、何を確認すべきかを考えていく。

 最後にテスト観点ごとにテスト条件を考える。ここでいうテスト条件とは、テスト対象の状態や与えるデータ、操作方法などのバリエーションのことだ。スケジュールやコストに制約があるため、あらゆるバリエーションのテストは非現実的だ。テスト計画で決めた優先順位を踏まえて網羅する基準を決める。

 テストケース作成方針はテストタイプごとの作成を推奨する。テストの目的やテスト範囲が異なるからだ。例えば、テスト計画で結合テストのテストタイプを「機能テスト、性能テスト、回帰テスト、疎通テスト、セキュリティテスト」と定義したなら、この5つのテストタイプごとにテストケース作成方針を作成する。

テスト範囲の画面を漏れなく洗い出す

 ここからはECサイトを例に、テストケース作成方針を決定するための具体的な進め方を説明しよう。あるECサイトで「商品の配送希望日時を選択可能にする」というシステム改修要件があり、結合テストで実施する機能テストの検討が必要であるとする(表1)。

表1●システム改修とテスト計画の概要
表1●システム改修とテスト計画の概要
[画像のクリックで拡大表示]

 最初にテスト範囲を考える。今回は画面一覧を基に整理する。テスト範囲の画面を漏れなく洗い出すために(1)要件と機能・画面の対応、(2)システムの使われ方、(3)改修に伴う影響、という3つの観点で検討する。なお、前段(ここでは単体テスト)のテストで確認した内容も考慮する。これはテスト範囲、テスト観点、テスト条件で共通だ。

 (1)要件と機能・画面の対応では、要件を実現する機能を洗い出し、それらを構成する画面を挙げる。今回の要件に必要な機能は「エンドユーザーが配送希望日時を選択する機能」「配送希望日時をデータベースに登録する機能」となる。この機能を構成する画面としては、エンドユーザーが配送希望日時を選択する「配送オプション選択画面」、配送希望日時をデータベースに登録する「商品購入確認画面」だ(図3)。

図3●要件を実現する機能、画面の特定
図3●要件を実現する機能、画面の特定
[画像のクリックで拡大表示]

 (2)システムの使われ方では、ユーザーシナリオを検討する。ユーザーシナリオとは「エンドユーザーが実際にシステムを使う際、どんな目的でどういった手順で使うのか」を示したものだ。ユーザーシナリオから画面の使用順序を理解して、画面や機能間の連携、データの流れを整理する。その上で、影響がありそうな箇所をテスト範囲に追加する。

 例えば「商品購入時、エンドユーザーが配送希望日時を指定する」というユーザーシナリオでは、商品購入画面→配送オプション選択画面→商品購入画面→商品購入確認画面→商品購入完了画面、という使われ方になる。

 仕様書などに明記されていなくとも、実際に利用者が使った場合を考慮すると追加すべきテスト範囲が見えてくる場合もある。今回の例では「商品購入後、エンドユーザーが配送希望日時を確認する」というユーザーシナリオが想定できる。開発者に仕様を確認したところ、「商品購入履歴詳細画面」にもエンドユーザーが選択した配送希望日時を表示すると分かった。そこで「商品購入履歴詳細画面」もテスト対象に追加した。

 (3)改修に伴う影響では、改修の影響を受けそうな箇所をテスト範囲に追加する。今回、改修によって注文明細データに「(エンドユーザーが指定した)配送希望日時」という情報が追加される。そのため、注文明細データを参照している画面には影響を及ぼす可能性がある。注文明細データを参照する「クチコミ投稿画面」は、変更がなくてもテスト範囲にする。

 このようにテスト範囲を考え、表2のように一覧に「○」を付けていく。画面名や機能名をテキストで列挙するのではなく、一覧表を利用するのがポイントだ。抜けや重複を防止でき、関係者間の認識共有に役立つ。一覧表としては、画面一覧や機能一覧などがある。

表2●画面一覧を用いたテスト範囲の表現
表2●画面一覧を用いたテスト範囲の表現
[画像のクリックで拡大表示]