ソフトウェアテストは、テスト対象の各機能に対して、明確な方針を定めて実施に取り掛かることが重要です。
どの機能を、どのような内容でテストするのかは、品質を左右する重要な要素となってきます。
今回は、テスト内容や方針をまとめるテスト仕様書について、作成時のポイントや、混同されやすいテスト計画書との違いについてご紹介します。
テスト仕様書とは？
テスト仕様書とは、ソフトウェアが要件定義書に記載された機能仕様通りに実装されているかどうかをテストするためのポイントをまとめたドキュメントのことです。
開発工程における要件定義のフェーズでは、予算やスケジュール、運用方法などをクライアントと打ち合わせて決めるのと同時に、必要な機能や要求もまとめます。要件定義でまとめた機能や要求を満たしているかどうかが、最終的にクライアントの満足度や評価につながります。
そのため、要件定義でまとめた機能や要求が開発で落とし込まれているかどうかを確認するため、テスト仕様書を作成してテストを実施します。一般的にテスト仕様書の作成は次の工程で進みます。
- テスト計画書→テスト分析・設計→テスト仕様書
テスト計画書で、テストにおける設計や実施、管理に伴う必要作業などをまとめて、テスト分析・設計工程でテスト対象のシステムについてテスト項目を洗い出したうえで、テスト仕様書の作成に取り掛かります。
テスト仕様書を作成する目的
テスト仕様書はテストするべき機能一覧やテスト技法など、テスト実施に必要な情報をまとめて、誰でもテストが行えるように作成します。
開発業務におけるテスト工程は、必ずしもプログラマーが行うとは限らず、テスターやデバッガーが行う場合もあります。その場合、開発に携わっていないメンバーはテスト仕様書がなければ、テストで用いる技法や実施手順の詳細がわからず、十分なテストを行えません。
誰がテストしても一定以上の品質を確保できるよう、テスト仕様書を作成する必要があります。
テスト計画書との違いは？
テスト仕様書がテスト実施のための詳細な要件を記載するのに対して、テスト計画書はテストに必要な人員やスケジュール、方針などテスト全体に関わる要件をまとめます。
テストに関するドキュメントとしてどちらも混同されがちですが、テスト計画書で決められた要件をもとに、テスト仕様書でよりテストの詳細を詰めるものと覚えておきましょう。
テスト計画書に関する詳しい内容は次のページで解説しています。ぜひ参考にしてみてください。
テスト仕様書に記載する項目
テスト仕様書は、その後のテストをスムーズに進めるためにも重要となりますので、記載すべき項目は押さえておきましょう。
テストの目的と背景
テストを実施する目的と背景について整理して記載します。システムを作成するに至った経緯も踏まえて、テストによってどれぐらいの品質が保証されるべきなのかを明確にします。
前段階のテスト計画書作成時に設定する内容ではありますが、仕様書作成の段階で再度確認して、記載しておきましょう。
重要テスト項目
テストを実施する上で特に重要となるテスト項目が何かを記載しましょう。
ユーザがメインで利用する機能やお金が動く決済システム機能、セキュリティ周りなど、注力すべきテスト項目について明確にします。
プロセス定義
テストプロセスとは、テストを進める際の作業の流れのことを指します。ここでは、主にテスト毎の開始基準や終了基準を定義します。
テスト実施者がこの基準に基づいてテストを行い結果をまとめるため、プロセスを明確に定義することが重要です。
アプローチ
テストをどのように効率よく行うのか、方法や手順を決定します。アプローチ次第でテスト方針も大きく変わるため、重要な要素となります。代表的なアプローチには、次の7つがあります。
分析的アプローチ
リスクの高い箇所や、ユーザーの業務フローにおける優先度などを分析して、そこを重点的にテストする進め方です。
モデルベースアプローチ
統計モデルなど、既存のモデルに基づいてテストする進め方です。統計データに基づいてユーザの使用頻度の高い機能などを割り出して、重点的にテストを進めます。
方法論的アプローチ
仕様や不具合を発見するための方法論に基づいてテストを進めます。エラー推測やフォールト攻撃を基にしたテストや、あらかじめ用意したチェックリストに沿ってテストを進めます。
プロセス準拠/標準準拠アプローチ
業界固有の標準に基づいたり、スクラム開発やアジャイル開発などの利用している開発プロセスに則ってテストを進めます。
動的で経験則に基づいたアプローチ
テスト設計者やテスターが、自身の経験に基づいてテストケースを実行したり、改良していく進め方です。
コンサルテーションベースアプローチ
対象システムの分野において深い知見のある専門家の助言や指導をもとにテストを進めます。
回帰的アプローチ
既存のテストを再利用したり、繰り返し実行できるテストを自動化してテストを進めます。アプローチはテスト計画書に記載するケースが多いですが、テスト仕様書に記載するケースもあります。
テスト対象機能（要素）一覧
どの部分をテストする必要があるのか、テスト対象の機能を一覧としてまとめます。機能は画面単位で操作性などをテストするものもあれば、データの状態単位でテストするものもあります。
これらを、画面や状態、モジュールなどといった単位で適切に分割して、テストが実施しやすいようにテスト仕様書に落とし込んでいくことが重要です。
テスト仕様書の作成時のポイント
テスト仕様書を作成する際のポイントについてご紹介します。
誰でもわかりやすいように記載する
テスト仕様書をもとにテストが行われるため、開発に携わっていないテスターやデバッガーが仕様書に目を通すケースは多いです。そのため、仕様書の内容は誰でもわかりやすいように記載しましょう。
テスト観点のレビューを行う
テストを行う上で必要になってくる考え方や切り口のことをテスト観点といいます。テスト観点はテスト仕様書を作成する際にも必要となってきますが、テスト観点がまとまった時点でレビューを行いましょう。
特に、要件定義書をまとめたメンバーは、開発対象のシステムに対しての知見が深いため、そのメンバーにレビューをお願いするのが効果的です。テスト観点については、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
テストすべき機能はすべて洗い出す
テストすべき機能は、一覧にしてすべて洗い出しましょう。要件定義書を参考に、機能の規模に応じて大項目、中項目、小項目とカテゴライズしていくと整理されてより把握しやすくなります。抜け漏れを防ぐためにも、機能の洗い出しは重要です。
テスト観点はわかりやすくまとめる
テストケースは、テスト観点をもとに作られます。途中からプロジェクトに参加したメンバーや、開発に携わっていないテスターやデバッガーでもスムーズにテストを行えるためには、テスト観点をわかりやすくまとめた上で、テストケースが作られなければなりません。
【まとめ】わかりやすいテスト仕様書を作成しよう
テスト仕様書は、テストケースを作成するための必要事項がまとめられているドキュメントです。
誰が目を通してもわかりやすい内容にすることで、誰がテストを担当しても抜け漏れがなく、品質を担保できます。仕様書に記載するべきポイントをおさえて、わかりやすいテスト仕様書を作成しましょう。
