テスト自動化をサクサク進めるためのWebマガジン「SAKUTES(サクテス)」 » テスト設計とは?【ソフトウェアテスト基礎知識】

テスト設計とは?【ソフトウェアテスト基礎知識】

テスト自動化をサクサク進めるためのWebマガジン「SAKUTES(サクテス)」 » テスト設計とは?【ソフトウェアテスト基礎知識】

ソフトウェアテストの工程の一つ「テスト設計」について解説します。このページでは、テスト設計の目的とテスト設計でのプロセス、テストドキュメントやテストケースについて情報をまとめています。

テスト設計とは

テスト設計とは、テストを行う手段を決めることをいいます。具体的に決めるのは、次の内容です。

上記の事項をテスト設計書にまとめるのが、テスト設計です。テスト設計は、テスト分析が済んだのちに行われます。テスト設計はどのようなテスト観点でテストするかを決定しますが、テスト観点はソフトウェアの機能を理解していないと定義ができません。ソフトウェアの機能を理解するために、まずはテスト分析が行われるのです。

テスト設計の目的

テスト設計の目的は、大きく3つあります。

1つ目が、抜けや漏れのないテストケースを生成することです。2つ目が、バグの検出率の高いテストケースを生成すること。そして3つ目が、項目数が少ないテストケースを生成することになります。

テストケースは機能仕様書から直接コーディングすると、プログラムにひずみが生じてしまい、抜け漏れが多々発生してしまいます。テスト設計では対象を大きな視野で捉え、徐々に視野を絞っていきます。

テスト設計の最終形は「テストケース」と呼ばれます。テストケースは手順書のことで、テスト対象物の最初の状態から操作方法、その結果からの確認事項や判断方法などが記載されています。テストケースは中間成果物をいくつか作りながら設計・生成していきます。これを、段階的詳細化と言い、問題が起きないように回避するためのものです。テスト設計をしないでテストケースを作成すると、さまざまなトラブルが起きる可能性があります。テスト設計の段階的詳細化の見解は、テスト設計の目的に応えるために必要なものになります。

テスト設計でのプロセス

テスト設計でのプロセスは、段階的詳細化の考えで組み立てられており「テスト基本設計プロセス」「テスト詳細設計プロセス」「テスト実装プロセス」などがあります。これらの段階には考慮すべきポイントなどがあり、そのポイントを踏まえてテスト設計することで、効率化を図ることができます。テスト設計の各プロセスは、テストの質の向上には欠かせないものです。

テスト設計では、「テスト設計仕様書」「テストマップ」「機能動作確認一覧」「テスト明細」「テストケース」の5つのテストドキュメントを作成します。このドキュメントによって、どのようなテストを実施するのかを分かりやすく記録することができます。

このテスト設計プロセスは、「QUINTEE」に基づくものです。

テスト基本設計プロセス

テスト設計プロセスでは、テスト対象の機能を、大きく捉えなければなりません。そのシステムに必要なテストの指針を決め、テストに使用するデータや環境に必要なものを検討します。テスト基本設計プロセスでは、テストを行う際に用いるテストケースは生成しません。テストケースに記述されるのは、テストの対象物をどのような状態でどのように操作をするかです。さらに、その結果の確認事項と判定方法について、具体的に記述されます。

テスト詳細設計プロセス

テスト詳細設計プロセスは、テスト基本設計プロセスに基づき、より詳細にテストを設計していきます。テストにはどのようなデータや環境が必要かなど、具体的な内容を決めていかなければなりません。

テスト実装プロセス

ここまで検討してきた内容を基に、テストケースを生成していきます。テストデータの作成・テスト環境のセットアップなどを行い、テストを行うための準備をすることをテスト実装プロセスと言います。

テストドキュメントとは?

テストドキュメントは、テスト設計の段階で生成された中間成果物のことです。テストケースの生成に至るまでに生成されたテストドキュメントは、テスト設計をした理由を表すものになります。テストドキュメントがあることによって、テストケースの意図が分かりやすくなり、テストの再利用性の向上が可能になります。

テストドキュメントは、機能仕様書のベースにもなるものです。テストケースを漏れなく生成したり、仕様変更にも容易に対処できるという利点があります。

テストケースについて

テスト設計では、テスト条件を確認するためのテストケースを作ります。テストケースは、条件の漏れがないように作るものです。テストケースを作るための技法はさまざまあります。その技法を活用すれば、一定のルールに基づいたテストケースを作ることができるでしょう。テストベースの技法は「ブラックボックステスト技法」「ホワイトボックステスト技法」「経験ベースのテスト技法」の3つに分類することができます。

機能テスト

機能テストの目的は、利用者によってソフトウェアが仕様通りに動作するかを確認することです。利用者による入力と、利用者が得る出力を基にテストケースが作られますが、ソフトウェアの内部構造は意識されません。

ホワイトボックステスト

ホワイトボックステストは、ソフトウェアの内部の作りがソフトウェア設計通りに動作することを確認するのが目的です。プログラムであればフローチャートなど、内部構造を広い範囲にわたってテストケースを生成します。

非機能テスト

非機能テストでは、機能以外の要件を満たしていることを確認します。性能を確認するためのテストであれば、急激な負荷の変動や予期しないシステムダウンといった状況を想定してテストケースを作ります。

変更部分のテスト

変更部分のテストの目的は、欠陥の修正や仕様変更によって、テスト済みのソフトウェアに影響がないことを確認することです。変更部分のテストでは、すでにテスト実行までが済んでいるテストを繰り返し実行します。

テスト設計を行う時期について

開発時、開発の成果物が作られたとき、または作られた直後からテスト分析を行います。さらに、変更が入るたびにテスト分析の内容を見直さなければなりません。ですので、開発にかかわるプロセスのあらゆる時期で見直しは続きます。

テスト分析の結果、成果物に不備が見つかった場合に、成果物とテストの両方を見直さなければなりません。見直しにかかる時間を考えると、早い時期に行うのがよいでしょう。

テスト設計作業がうまくいっていない場合のトラブル

テスト設計がうまくいっていないと、テストの抜け漏れや過剰にテストをしてしまうといったトラブルが発生します。テスト対象を理解不足のままテスト設計を行うと、問題が起きやすくなります。

また、仕様変更や追加があったときには、テスト条件やテストケースを見直す必要が出てくるでしょう。その際、わからなくなってしまったり、誤ったテストケースが残ってしまう恐れもあります。

どの要件に対してどの程度のテストをしているのか分からなくならないように、要件とテスト条件の関係は紐づけしておく必要があるでしょう。

⽇本語のサポートが⼿厚い!
UIテスト自動化ツールを比較

ノンプログラミングで
⽇本語のサポートが⼿厚い

テスト⾃動化ツールを⽐較
商品名 Ranorex
(ラノレックス)
Autify
(オーティファイ)
商品タイプ パッケージ型

膨大なテスト工数を
削減したい企業向け

SaaS型

初期費用を抑えて
導入したい企業向け

対応テスト
  • デスクトップ
  • webアプリ
  • モバイルアプリ
  • デスクトップ
  • webアプリ
  • モバイルアプリ
実行回数
の制限
制限なし 制限あり

400回/1000回/任意 ※プランにより異なる

日本語サポート 導入後のセミナーが充実! ヘルプサイトが充実!
体験版 14日間 14日間

※Googleで「テスト自動化ツール」と検索し上位表示されたパッケージ型、SaaS型のテスト自動化ツール21種類の中から、(1)クロスデバイス、マルチブラウザに対応し、(2)日本語のサポートがあり、(3)ノンプログラミングでシナリオ作成が可能なツールをピックアップ(2021年11月1日調査時点)。パッケージ型、SaaS型それぞれの代表商品を選出しました。

【代表商品の選出基準】
☆パッケージ型:上記の条件の通り。
☆SaaS型:上記の条件に加え、公式サイト上に導入事例がもっとも多かったツールを選出。