テスト仕様書とは？計画書との違いや項目・書き方のポイントを解説
COLUMN

システムやソフトウェアのテスト品質向上に、テスト仕様書は欠かせません。ただし、テスト仕様書はテスト計画書と使用するタイミングや内容、目的に似た部分があり、ソフトウェアやシステムの開発に慣れていない方は勘違いするケースがあります。テスト仕様書とはどのようなもので、何を記入すればよいのか理解すれば、円滑にテストを実施できるでしょう。

この記事では、テスト仕様書とテスト計画書の違いや、テスト仕様書に必要な項目、書き方のポイントについて解説します。

1. テスト仕様書とは

テスト仕様書は担当者にテストの詳細を分かりやすく伝えて、スムーズなテスト実施を助けるために作成する書面です。

テストは成果物の品質保証を行うのに欠かせない工程です。開発の担当者が人間である以上、ヒューマンエラーやバグの発生を避けられません。納品後の修正対応を回避するためにも適切にテストを行い、トラブルを防止する必要があります。

システムやソフトウェアのテストは、プロジェクトに直接関わってきた人が担当するとは限りません。テストの工程で初めてプロジェクトに関わる人が正確な作業を行うには、テスト仕様書が必要です。

さらにテスト仕様書はテストの詳細をクライアントに共有し、認識を合わせる目的でも活用されます。テストの実施前にテスト仕様書を利用して認識合わせを行えば手戻りを回避でき、スケジュール通りに開発が進みやすくなります。

テスト自動化ツールならATgo
1か月トライアル無料：詳細はこちら

1-1. テスト仕様書とテスト計画書の違い

テスト仕様書とテスト計画書はいずれも、開発現場でテストを行う際の事前準備として作成される書類です。しかし、テスト仕様書とテスト計画書では以下の表の通り目的や作成のタイミングが異なります。

テスト計画書は「誰が何を・いつ・どのように確認、検証するか」といったテストの全体像を示す書類です。テスト仕様書には、テスト計画書で示された全体像をもとに整理したテストの詳細が記載されます。

テスト計画書について詳しく解説｜目的や記載方法・作成のポイントも

2. テスト仕様書の各項目

テスト仕様書は、テスト設計仕様書・テストケース仕様書・テスト手順書によって構成されます。それぞれの書類に記載すべき項目はある程度決まっているため、基礎知識として知っておくと役立つでしょう。

以下では、テスト設計仕様書・テストケース仕様書・テスト手順書に記載すべき項目の代表例を紹介します。

2-1. テスト設計仕様書

テスト設計仕様書とは、ソフトウェアやシステムの全体像をもとにテストの戦略を文章化したものです。テスト設計書は、テスト設計を進める際の指針としても機能します。

テスト設計仕様書に記載する主な項目は、以下です。

開発現場では自組織で使用している既存のテストプロセスを、プロジェクトごとにカスタマイズして採用することもあります。テスト設計書のプロセス定義は、カスタマイズした内容を共有するのに役立つ項目です。

テストアプローチでは「どの機能を、どのような視点でテストするか」を定義して、関係者へと提示します。具体的にはテストする機能とテスト観点を一覧表にまとめ、関係者へ提示することが必要です。

テスト環境では主に、テストの実施環境・使用機材・必要な事前準備を提示します。テストを実施するにあたってセットアップ作業やトレーニングが必要な場合はテスト環境に記載し、スムーズに事前準備できるよう配慮しましょう。

テスト設計とは？プロセスや失敗しないためのポイントを解説

2-2. テストケース仕様書

テストケース仕様書とは名前の通り、テストケースの仕様を定義する書類です。テストケースとは、テスト設計の方針を踏まえて作成される前提条件・入力値・期待値などのセットを意味します。

以下は、テストケース仕様書に記載する項目の代表例です。

テストケース仕様書ではテストを担当するメンバーが見た際、「何をどのように行えばよいか」を明確に把握できる記載を行うことが重要です。テストのインプット内容を記載する際には、具体的なパラメーターまで提示します。テスト手順は操作の工程ごとに行を分けるなどの工夫によって、スムーズな理解を後押ししましょう。

期待する結果は、どのような状態になれば「合格」と判断するかを示す項目です。たとえば、購入ボタンを押した際の端数処理を確認するテストでは「1円未満が切り捨てされ、1,300円（インプット内容に応じた金額）と表示される」などを記載します。

2-3. テスト手順書

テスト手順書は、テスト計画書で定められた各テストケースを実施する際の手順を詳細に説明する書面です。テスト手順書には主に、以下の項目を提示します。

複数機能のテストを行う場合には、テストケース別に実施手順を説明する必要があります。文章のみで説明しにくい場合はWBS（作業分解構造図）を追記し、詳細な手順を説明するのもやり方の1つです。

複数機能のテストを実施する際には通常、「予想される不具合が多いもの」から順番に行います。機能の複雑さに差がある場合は、準備する環境が複雑なものや、大量のテストデータが必要なものなど、時間がかかるテストを優先しましょう。

また、テストを実施しても不具合が検出されないなど、十分な信頼性が得られないケースがあります。そうした状況に備えて、テスト手順書にはテスト手順を変更する条件と対応方針を記載しましょう。

3. テスト仕様書の書き方のポイント

テスト仕様書の仕上がり度合いによって、システムなどの品質は大きく変化します。プロジェクトの成功をサポートするためにもテスト仕様書は、以下のポイントに注意して記載しましょう。

3-1. 仕様書を作る前に要件定義書を読み込む

テスト仕様書は、クライアントの要望を理解した上で作成する必要があります。クライアントの要望を理解できるよう、作成の事前準備として、要件定義書を読み込みましょう。そして、用件定義書の内容からテストする機能や動作の洗い出しを行った上で、テスト観点を検討し、明確化してください。

テスト観点に漏れや方向性の相違があると、テストの質に影響します。テストの質を高めるためには観点を検討した後、クライアントの意向を十分に理解している人のレビューを受けることも大切です。

たとえば要件定義書の作成者は、クライアントの意向やシステムの必要機能を深く理解しています。質の高いテスト仕様書を作成できるように、必要に応じてコミュニケーションを取り、内容のブラッシュアップを図りましょう。

要件定義とは？流れや要件定義書の内容・必要スキルも解説

3-2. 誰が読んでも解釈が変わらない記述を心がける

テストの手順や期待する結果を記述する際には誰が見ても容易に理解でき、スムーズに作業できる書き方を意識しましょう。インプット内容や合否判定基準についても、同様です。

以下は、テスト仕様書を分かりやすく記述するためのコツを示します。

注釈は、抽象的な表現になっている部分や誤認される可能性のある部分に追加します。テストで期待する結果や合否判定基準が文章で伝わりにくい場合には、画像の追加が必要でしょう。

粒度とは、説明の詳細レベルです。たとえば、4工程で行うテスト手順の説明ではすべての工程の詳細レベルをそろえて一貫性のある記述を行うと、見る人の混乱を回避できます。

まとめ