テスト仕様書とは? テストケースとの違いや良い仕様書、ダメな仕様書も紹介

最終更新日:

ダメな仕様書良い仕様書

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

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

 

 

 

テスト仕様書は、機能とテスト観点から成り立つ

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

 

それでは、テスト仕様書を作るうえで、必要なことは何でしょうか。抑えておくべき、ふたつのポイントを紹介します。

 


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

ひとつ目のポイントは、機能です。テストを行うために、まずはテストする機能をすべて洗い出す必要があります。 機能を洗い出す基となるのは、クライアントの要望をまとめた要件定義書です。この要件定義書を読み込み、テストを行う機能を大項目に分類。機能のサイズに合わせて、中項目、小項目とカテゴライズします。

 

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



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

ふたつ目のポイントは、機能が正しく動作した結果と、テストをするための要点をまとめることです。この内容を、テスト観点と呼びます。テスト観点は、機能を分類した中項目、もしくは小項目ごとに作ります。

 

このように、システムやソフトウェアをテストする上で、どんな機能があり、どのようなテストを行うのか、まとめたものがテスト仕様書の一部です。一部と言ったわけは、テスト観点をもとに作られるテストケースも含まれているからです。

 


テスト仕様書の観点をもとに、テストケースが作られる

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

 

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

 

そうしたエンジニアでも、正しくテストを行うために、テストケースには、「曖昧さ」があってはいけません。そのため、テストケースの前提となる条件やテストの方法、期待結果は具体的な数値やパラメータで記述する必要があります。



失敗しないテスト仕様書の書き方とは

結合テストを行うエンジニアは、テストケースをもとにテストを行うため、テスト仕様書の内容が十分に詰められていないと、実際のテストも十分な結果が得られない、ということが起こりえます。そうした失敗をしないテスト仕様書の書き方を紹介します。

 

 

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

システムやソフトウェアの品質は、テスト仕様書の出来に左右されるといっても過言ではありません。ダメなテスト仕様書によって、テストを行うエンジニアを混乱させてしまい、正しい結果が得られない、といったケースも見られます。それでは、ダメなテスト仕様書に共通するポイントは何でしょうか。

 

テスト観点が漏れている

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

テスト観点がずれている

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

テスト観点の表現が曖昧

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



良いテスト仕様書を作るために大切なのは、レビューと注釈

ダメなテスト仕様書の例を踏まえると、良いテスト仕様書の条件とは、漏れがなく、分かりやすいことにつきます。そのために、次のふたつのポイントを抑えて、テスト仕様書を作ってみましょう。

 

テスト観点のレビューで漏れやずれを防ぐ

テスト仕様書は、クライアントの要望をまとめた要件定義書から作られます。要件定義書をまとめた方が、開発するシステムやソフトウェアの機能をもっともよく知る方。テスト観点がまとまった時点で、レビューしましょう。 普段から、開発工程とテスト工程で、コミュニケーションが取れていることが品質向上につながります。 テスト観点の視点は、ひとつではありません。開発側だけではなく、ユーザー視点に立つことも、テスト観点の洗い出しに有効な方法です。

 

テスト観点の表現一つひとつに注釈をつけるイメージで

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



まとめ

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

テスト仕様書を、システムやソフトウェアの品質を高めるだけでなく、開発工程を改善するために、活用してはいかがでしょうか。

一つ先をゆくテスト管理ツール「Qangaroo」、
その真価を無料でご体感ください。

無料トライアル版では、Qangaroo のサポートチームとのコミュニケーションを通じて、
卓越したユーザーインターフェースや機能性をお確かめいただけます。今すぐトライ!

お問い合わせ 無料で試してみる