テスト設計書とは？仕様書との違いと目的・書き方のポイントを解説

テスト設計書とは、各工程で実施されるテストの方針や範囲を定義するドキュメントです。テスト設計書により定められた方針に従ってテスト仕様書を作成し、品質を確保します。適切なテスト設計書は、経験の浅いエンジニアやチーム全体のテスト品質向上に有効です。

この記事では仕様書との違いや目的、書き方のポイントを解説します。

テスト設計書とは？

テスト設計書とは、テストの方針を明確に定めたドキュメントです。

テストはシステムの品質を確認する重要な工程ですが、テスト設計者の経験やスキルにより精度が左右されるおそれがあります。テストの目的、範囲、観点、具体的手法、評価方法などを明文化することで、テスト工程を適切に管理し、一定以上の品質を確保します。

テスト設計書が適切であれば経験の浅いエンジニアでもテストの意図を理解し、漏れのないテストの実施が可能です。

テスト設計書とは個人のスキルに依存せず、組織全体において均一で高品質なテストを実現するために不可欠です。

テスト設計書を作成する目的

テスト設計書を作成する主な目的は以下の3つです。

テスト設計書は質の高いテストを可能にし、開発プロジェクト全体の効率と品質を高めるために不可欠な要素といえるでしょう。

テスト設計書とテスト仕様書の違い

テスト仕様書はテスト設計書で定められた方針に従い「具体的にどうテストを行うのか」を詳細に記述したものです。

各テスト項目について「どのような操作を行うのか」「どのような結果になるべきか」といった具体的な手順や期待値を明記します。テスト設計書とテスト仕様書は密接に関連していますが、その役割と記述レベルが異なります。

適切なテスト設計書によりテスト仕様書の作成が円滑に進み、より効率的で質の高いテストが実現できます。

関連記事：テスト仕様書の作成方法とは？作成の目的や書き方、注意点を解説

テスト設計書の書き方

テスト設計書に記載する主な内容と書き方は以下の通りです。それぞれ詳しく解説します。

• システムの概要、日付、改訂履歴の記載
• テスト目的の明記
• テスト対象と範囲の確定
• テスト内容の記載
• 合格基準の決定
• テスト環境の記載

システムの概要、日付、改訂履歴の記載

テスト設計書の冒頭には、システムの概要、作成日付、そして改訂履歴を記載します。

システムの概要を記載することで、レビュワーや後からプロジェクトに加わるメンバーが、システム全体の背景を理解できます。

作成日付と改訂履歴はテスト設計書が最新か、どのような変更が加えられてきたのかを追跡するために必要です。基本的な情報の記載はシステム全体像の理解を助け、テスト設計書の信頼性と有効性を高めます。

テスト目的の明記

テスト設計書では「なぜこのテストを行うのか」というテスト目的を明確にすることが重要です。

システム開発の関係者全員が当該のシステムが何を達成するものであり、どの程度の品質を満たすべきかをすべて理解しているとは限りません。テストの目的を明確にすることで、「何のためのテストか」という共通認識を持て、優先順位付けなどを適切に実施できるようになります。

これによりテストは明確なゴールを持った活動となり、目標に向かった効率的なテストの実施につながるでしょう。

テスト対象と範囲の確定

テスト設計書では、ユーザーの目的を満たすために必要なテスト対象を定めることが重要です。

開発プロジェクトには時間やリソースの制約があり、すべての機能やパターンを網羅的にテストすることは現実的に困難です。

そのため、以下のケースを優先してテスト対象を設定します。

• ビジネス価値が高い機能
• 不具合が発生した場合に大きなインパクトを与える機能
• 利用頻度が高く多くのユーザーが使う機能

また、「やらないこと」を明確にして手戻りを防ぎ、コストと工数の超過を防止することも重要です。

例えば、「サポート終了済みブラウザはテスト対象外とする」「エンジニアがメンテナンスするときにしか使用しない機能はテスト対象外とする」といったケースです。

テスト対象と範囲を事前に確定し関係者間で合意することで、効率的なテスト計画の立案と円滑なプロジェクトの推進が実施できるでしょう。

テスト内容の記載

テスト設計書の具体的な記載要素は以下の4つです。

これらの4要素を組み合わせてテスト内容を記述します。

例えば、「単体テスト」レベルで「機能テスト」タイプの「入力値の正常系」観点で「同値分割法」によりテストケースを作成するといった組み合わせになります。

テスト観点が細かくなりすぎると、仕様変更時のテスト内容変更やドキュメントの版数管理が負担になるため、重要なポイントに絞ることが大切です。

合格基準の決定

テストをどこで終了させるのか、事前に合格基準を定め終了時期を明確にすることは重要です。

不具合をすべて発見するために際限なくテストを続けてもすべての不具合の解消は難しく、かえって費用対効果が低下します。

以下のような合格基準を設定することで、過度なコストをかけずに品質と費用対効果のバランスをとることが可能です。

• 重要度の高い未解決の不具合がないこと
• テストカバレッジが〇％以上であること
• 直近の信頼度成長曲線（バグ成長曲線）が収束傾向にあること

合格基準が明確であればプロジェクトチームはゴールを意識して作業を進められ、スケジュール遅延の防止につながります。

テスト環境の記載

テスト設計書には発見した不具合の再現性を高めるために、テスト環境を詳細に記載する必要があります。

テスト環境はハードウェアとソフトウェアの両面を詳細に記述することが重要です。

具体的には以下のようにテストに使用する項目です。

• パソコンのスペック（CPU、メモリ）
• スマートフォンの機種やタブレットのモデル
• OS（オペレーティングシステム）の種類とそのバージョン
• 使用するブラウザの種類とバージョン
• テストに必要なミドルウェアやライブラリのバージョン
• アカウント情報や、事前に準備すべきデータ

これらの環境情報が詳細に記載されていれば、他のエンジニアが同じ環境を構築してテストを実行でき、不具合の再現確認が容易になります。

テスト環境の記載は効率的なデバッグ作業を支援するために重要な要素といえるでしょう。

テストにおける問題点

質の高いテスト設計をすればするほど、実行すべきテストケースが膨大になり、以下の問題が発生します。

• テストケースの増加により、多くの時間と人的リソースが必要になる
• 要件の変更や仕様の追加が発生するたびにテスト設計書も改版が必要となり、維持コストが増加する
• テスト設計書の改訂が遅れると、実際のシステムの状態とテスト設計書の内容が合わなくなり、ドキュメントが陳腐化する
• 陳腐化したテスト設計書では適切なテストが実施できず、不具合を見逃すおそれがある

テスト設計書の目的である「テスト品質の確保」や「共通認識の形成」が果たせなくなり、結果的にテストの信頼性や効率性が低下するリスクが生じるのです。

Autifyによるテストの自動化

「Autify Nexus」はノーコードでテストの実行とメンテナンスを自動化し、テストプロセスの生産性向上を可能にするテスト自動化プラットフォームです。

「Autify Nexus」では以下のようなことができます。

• チャットでの指示と直感的な操作で誰でも自動テストを作成できる
• 高速で回数無制限のテストが実施できる
• 高度な自動追尾機能により、システムの変更を自動的に反映できる

「Autify Nexus」は作業負荷・人的負担の軽減、コストの低減、属人化・陳腐化を防止し、全社のテスト品質向上と生産性向上を実現できるソリューションといえるでしょう。

まとめ

テスト設計書はテストの方針や範囲を定義するためのドキュメントで、品質の向上だけでなく企業全体の品質向上に寄与します。

しかし、適切なテスト設計書を維持するためには、多大なメンテナンスのコストが必要です。

テスト自動化プラットフォームである「Autify Nexus」は人的コストをかけずにテストの実行と保守を自動化し、システムの品質向上と生産性の向上が期待できます。

自社の企業戦略達成のために、「Autify Nexus」によるテスト自動化を検討してはいかがでしょうか？