テスト仕様書は、システムやソフトウェアの品質を高めるために欠かせないドキュメントです。システムやソフトウェアの開発において、作成されるドキュメントの種類は多く、呼び方も似通っていることから、ほかのドキュメントと混同している方も多いのではないでしょうか。

この記事では、テスト仕様書とは何か、概要と併せて、混同しやすいテスト計画書やテスト設計書、テストケースとの違いを説明します。 さらに、良いテスト仕様書を作るポイントと、ダメなテスト仕様書の事例も紹介します。

テスト仕様書とは？

テスト仕様書とは、システムやソフトウェアが、クライアントのヒアリングをもとに作り上げた要件定義書の通りに機能するかどうか、テストするポイントをまとめたドキュメントです。

具体的には、結合テストや総合テストの工程でどの機能を、どのテスト技法を使ってテストするのか記されています。

テスト仕様書と混同しやすい3つのドキュメント

システムやソフトウェアのテストを行う上で、様々なドキュメントが作成されます。その中でも、テスト仕様書と混同しやすいドキュメントが3つあります。そのドキュメントとは、テスト計画書、テスト設計書、テストケースです。

テスト計画書との違いとは？

テスト計画書は、システムやソフトウェアテストのテストの方針を決めるドキュメントです。テストの目的や範囲、人員やスケジュール、終了基準など、テスト全体に関わる要件がまとめられています。

そのため、テスト計画書には、結合テストや総合テストなど各工程で行われるテストで、どの機能を、どのテスト技法を使ってテストをするのか、といった詳細な情報は記されていません。そうした情報は、テスト仕様書に記されています。

テスト設計書との違いとは？

テスト設計書は、テスト仕様書と同じドキュメントを指し、テスト設計仕様書と呼ばれることもあります。結合テストや総合テストの工程で、どのような機能をテストするのか、テストで使うテスト技法は何かといった、具体的な内容が記されています。

テストケースとの違いとは？

テストケースには、エンジニアが実際のテストをするために、前提となる条件や、テストの方法、そのテストによって得られる正しい結果（期待結果）が記されています。

このテストケースは、テスト仕様書にまとめられている、各機能のテストの方法に合わせて作られます。つまり、テストケースはテスト仕様書の一部といえます。

テスト仕様書を作成する上で大切な4つのポイント

結合テストや総合テストを行うエンジニアは、テストケースを元にテストを行います。システムやソフトウェアの品質は、テスト仕様書の出来に左右されるといっても過言ではありません。良いテスト仕様書を作成するために大切な4つのポイントを紹介します。

テストすべき機能をすべて洗い出す

テスト仕様書に、テストすべき全ての機能を記すために、クライアントの要望をまとめた要件定義書を読み込みます。この要件定義書からテストすべき機能を洗い出し、テストを行う機能を大項目に分類。機能のサイズに合わせて、中項目、小項目とカテゴライズします。

テスト仕様書で機能を洗い出すメリットは、思わぬ機能の漏れが見つかることです。また、「これって必要な機能なんだっけ？」といった発見があるので、曖昧な機能の再定義にも役立ちます。

テストの道筋をテスト観点でわかりやすく示す

テスト仕様書には、機能をテストするための切り口をまとめます。これをテスト観点と呼びます。検索機能であれば、「正しくデータを取得できているか確認する」「検索結果が0だった場合の挙動を確認する」などがテスト観点になります。

テストケースは、このテスト観点を元に作られます。ここで、イメージしてください。テストを行うエンジニアは、機能の内容をすべて理解しているわけではありません。場合によっては、テストのためだけに、プロジェクトの途中から参加しているエンジニアもいるかもしれません。

そうしたエンジニアでも迷うことなくテストを行える、テストケースを作る必要があります。そのためには、どんなテストを行うのか、誰もがイメージできるテスト観点が大切なのです。

テスト観点をレビューする

テスト仕様書は、クライアントの要望をまとめた要件定義書から作られます。要件定義書をまとめた方が、開発するシステムやソフトウェアの機能をもっともよく知る方。テスト観点がまとまった時点で、レビューしましょう。レビューを行うことで、テストを行うべき機能の漏れを防ぐことができるからです。

テスト観点の視点は、ひとつではありません。開発側だけではなく、ユーザー視点に立つことも、テスト観点の洗い出しに有効な方法です。また、開発工程とテスト工程で、積極的にコミュニケーションを取ることも、テスト観点の洗い出しにつながります。

テスト観点に注釈をつける

「このテスト観点から、どんなテストケースを作るの？」と確認されるようでは、良いテスト仕様書とは言えません。誰でも、確認する必要がなくテストケースを作れるテスト仕様書を作成するポイントは、表現の一つひとつに注釈をつけるイメージで記述することです。

例えば「条件」という表現をした場合は、どのような条件なのか、数値やパラメータなど、誰が読んでも間違えようのない記述を心がけましょう。テスト観点を作った方でなくても、テストケースが作れるくらい、具体的でわかりやすい表現を心がけましょう。

ダメなテスト仕様書を作ってしまう3つの落とし穴

ダメなテスト仕様書によって、テストを行うエンジニアを混乱させてしまい、正しい結果が得られない、といったケースも見られます。それでは、ダメなテスト仕様書に共通するポイントは何でしょうか。

テスト観点が漏れている

システムやソフトウェアの要件定義書の読み込みが充分でない場合に起こりえることです。テストすべき機能は洗い出されているのに、テスト観点が漏れてしまうと、テストケースも作られないため、機能が正常に動作するのかどうか、エンジニアはテストすることができません。

テスト観点がずれている

要件定義書を読み込んでいたとしても、テスト観点がずれていると、テストの目的や方法もずれてしまいます。いくらテストケースを詰めたとしても、正常な動作かどうか、判断するための結果は得られません。

テスト観点の表現が曖昧

表現が曖昧なテスト観点からは、正しいテストケースを作ることはできません。例えば、「条件」といった表現を使った場合、どのような条件なのか詳しく表現しなければ、テストを行うたびに結果が異なる、という事態に陥ります。

ダメなテスト仕様書の例を踏まえると、良いテスト仕様書の条件とは、漏れがなく、分かりやすいことにつきます。

まとめ

テスト仕様書を作るメリットは、システムやソフトウェアの機能が明確になり、機能が正しく作動するのかどうか、誰がテストしても正しく検証することができることにあります。

開発に入る前にテスト仕様書を作ることができれば、開発の手戻りを減らすことも可能になります。テスト仕様書を、システムやソフトウェアの品質を高めるだけでなく、開発工程を改善するために、活用してはいかがでしょうか。