テスト設計の基礎

テスト設計の段階的詳細化

本レッスンでは、テストの一連を体系化した「QUINTEE(クインティ)」における、テスト設計の全体像を説明します。
各メソッドの具体的な内容は、本コンテンツ内からリンクしている別の解説コンテンツをご覧ください。

QUINTEEテスト設計エリアの全体像

テスト設計を実施する際には、大まかな部分から細かい部分へと粒度を段階的に細かくして進めていく必要があります。
以下に、QUINTEEにおけるテスト設計エリアの全体イメージを記します。

図1:QUINTEEテスト設計エリアの全体像

上記の横方向は、テストドキュメント(テスト設計の成果物)の一般的な作成順を表しています。
縦方向は、抽象的なものから段階的に詳細化・具体化されることを表しています。
テスト設計のプロセスは、大きく分けて3つの段階(プロセス)に分けられています。

 ・テスト基本設計プロセス
 ・テスト詳細設計プロセス
 ・テスト実装プロセス

これらテスト設計の各段階には、明らかにすべきものや考慮すべきポイントがいくつかあります。
そのポイントを踏まえてテストを設計し、適切なフォームでドキュメント化することで、テスト設計の効率化が図れます。
また同時に、「テストの抜け漏れの防止」「バグを抽出する可能性の向上」「テストケースの項目数削減」「テスト実施のしやすさや正確性の向上」といった、テストの質の向上に寄与します。

このように、テスト設計の結果をドキュメント化することは、テスト設計の質を向上させるためにはなくてはならないものです。テストの設計は、単に手を動かすだけの作業ではなく、非常に高度な技量を要する知的で生産的な活動です。これらを人の頭の中だけに留めてぼんやりとした状態にするのではなく、ドキュメント化することで曖昧さを排除し、「そのテストの意味や意図」をはっきりさせていくことがとても重要です。

ドキュメント化することはテストを設計する上で無くてはならないものですが、そのメリットは他にもあります。
まず挙げられるメリットは、それぞれの成果物を作成した段階で妥当なレビューが可能になることです。これはテストドキュメントの目的を明確にすることによって、「そのドキュメントで何ができていればいいのか」が明確になり、レビューの観点も明確になるからです。
他にも、そのテストの意味や意図がドキュメント化されていることでテストの再利用性が高まること、要件とテストのトレーサビリティが確保できることが挙げられます。

QUINTEEの考え方はさまざまなテストタイプに使用できるものですが、現在提供しているテンプレートや作成演習は、機能確認テストを想定しているものです。

QUINTEEの流れと成果物

それでは、ここからはQUINTEEの内容を順に見ていきましょう。
「図1:QUINTEEテスト設計エリアの全体像」にあるように、QUINTEEでは、テスト設計を3つの段階(プロセス)に分け、おのおのの段階で検討した結果を中間成果物として作成していきます。

テスト設計の最初のインプットは、「テスト計画書」「開発仕様書」「開発者からのヒアリング内容」などです。それらの情報を基に、段階的にテストを設計して、最終的には「テストケース」を作成することがゴールとなります。

テスト設計やテスト実装プロセスの概要については、テスト設計について解説した記事をご参照ください。

テストケースを生成するために、あるいは「どのようなテストを実施するのか」を検討し分かりやすく記録しておくために、いくつかのドキュメントを作成します。

具体的には、以下の5つのテストドキュメントを作成します。

  • テスト設計仕様書
  • テストマップ
  • 機能動作確認一覧
  • テスト明細
  • テストケース

以降で、それぞれのドキュメントの概要を説明します。詳しい内容や作成方法については、個別の解説記事をご覧ください。

テスト設計仕様書

テスト設計の方針を記載したドキュメントです。一連のテスト設計ドキュメントの中では、文章で説明する部分がもっとも多いドキュメントです。もちろん、文章だけではなく、図や表を使って分かりやすく記載する箇所もあります。

テスト設計仕様書で特にポイントとなるものは、以下の2点です。

  • テスト対象をどの要素のまとまりに分割するのか(テスト対象機能)
  • テスト対象に対し、どのようなアングルのテストを実施するのか(テスト観点)

上記の2点はテスト計画書の段階で概要が定められていることも多く、それを詳細化していきます。

図2:テスト計画書からテスト設計仕様書へ
図2:テスト計画書からテスト設計仕様書へ

また、個別のプロジェクトやチームによっては、テストの設計や実施方法は個別にルールやノウハウがあるものですが、それらもテスト設計仕様書に記載します。その理由は、チームを適切に統制するためです。いかに優秀なエンジニアがいたとしても、その足並みがそろっていなければ、プロジェクトを適切に進行させることは困難です。
よって、冒頭部分で記したとおり、テスト設計仕様書は、テスト設計を行う上での方針を定めたものと捉えるとよいでしょう。

テストマップ

テストマップは、テストの全体像を把握するためのものです。

図3:テスト設計仕様書からテストマップへ
図3:テスト設計仕様書からテストマップへ

テスト設計仕様書で定義した、「テスト対象機能」と「テスト観点」を組み合わせてマトリクス化したフォームになっており、個々のテスト対象機能に対し、どんなテストを行うかを明確化します。テストを実施する場合はその重要度を定義します。
上記のように整理することで、テストを実施する部分が把握できると共に、テストにかけられるリソースに応じてテスト内容の調整がしやすくなります。

機能動作確認一覧

「テスト対象機能」に対する動作確認を検討する際に、それぞれに固有の確認内容を具体化して一覧にしたものです。テストマップだけでは検討できない、個々の機能に関するテスト内容をここで明らかにします。その検討の際は、開発仕様書の内容のみをなぞってテストを考えるのではなく、「何ができれば正しいのか」「何ができなければ正しいのか」「何が起こってはいけないのか」を考えることがポイントとなります。

図4:機能動作確認一覧の例
図4:機能動作確認一覧の例

テスト明細

テスト明細では、上述のテスト設計仕様書・テストマップ・機能動作確認一覧で検討した内容を基に、具体的なテストの条件を検討していきます。

テストマップや機能動作確認一覧で検討した項目を一覧にし、その内容をテストするうえで必要なパラメータの種類やそのバリエーションの数などを検討していきます。また、この段階で実際のテスト実施を意識し、同時に実施できるテストなどを整理したり統合したりして、テストの組み立てをデザインします。

図5:テスト明細の例
図5:テスト明細の例

テストケース

最終的にテスト担当者が使用する形にまとめたものがテストケースです。ここまでのテストドキュメントの中でもっとも具体的な内容が記載されており、テストオペレータは、基本的にはこのテストケースだけを見て操作し、テストのOK/NGの結果を記入することが可能となるような記述粒度を目指します。つまり、操作手順や入力パラメータ、そして確認するべき期待結果が項目ごとに明確に具体的に記載されていることが重要です。

QUINTEEの使い方

ここまで説明してきた内容に関して、ひとつお伝えしておきたいことがあります。それは、「いつ、いかなる場合でもQUINTEEで定義するテストドキュメントをすべて作成することは必須ではない」ということです。
たとえば、非常に短期間(たとえば1週間)でテストを計画し、設計して実施するようなプロジェクトでは、上述のテストドキュメントの一連をすべて作成することは現実的ではないでしょう。そのような状況では、テストドキュメントを一式すべて作成するのではなく、そのプロジェクトに必要なドキュメントを適度な粒度で作成することが必要になります。

具体的な例として、テストマップというテストドキュメントを作成する場合を考えてみましょう。
テストマップを作成する標準的な手順としては、該当する機能と該当する観点に対して、テストを実施するべきかどうか、そして実施するのであればその機能-観点の重要度を検討し、設定していきます。この重要度の設定という作業は重要ではありますが、時間がそれなりにかかります。そこで、まずテストを実施する必要があるか、それとも実施する必要のない部分なのかを明確にする、という目的を果たすため、とりあえずテストマップのテスト対象箇所に○をつけていく、というやり方もあります。はじめにテストの実施箇所についての合意を関係者の間で取り、詳細の重要度についてはそのあとに検討する方が効率的な場合はそのようなやり方がふさわしいこともあります。

つまり、ドキュメント化はテスト設計に欠かせないものではありますが、ドキュメント化すること自体が目的ではないということです。そのドキュメントを作成することで、テスト設計のその段階で何を明らかにすべきかを明確化している、ただそれだけのことなのです。
テストドキュメントを作成すること自体に目を奪われず、テスト設計のその段階では何を明らかにすべきなのか、テスト設計の思考プロセスを理解し、そのプロジェクトで必要とされるふさわしい成果物を作り上げることが、とても重要です。

おわりに

ここではQUINTEEについての全般的な考え方や各テストドキュメントの概要を説明しました。テスト設計プロセスは、テストに求められている抽象的なニーズから具体的なテストケースを、段階を踏んで作り出していくプロセスであり、テストが成功するか失敗するかを左右する重要な役割を担っています。このQUINTEEの考え方をベースに、必要な作業を漏れなく、無駄なく実施していくことが、良質なテストを実行すること、ひいてはプロジェクトの成功への第一歩となるでしょう。