テスト設計仕様書とは

テスト設計仕様書とは、ソフトウェアやシステムのどの部分を、どのようにテストするかについてまとめたドキュメントのことです。このドキュメントがあるおかげで、テストをどのような観点や方針で行うのかが明確になり、テストの抜け漏れを防止します。
テスト設計仕様書が作成されるのは、テスト基本設計やテスト詳細設計が固まった後で、テストが実施される前になります。このタイミングでテスト設計仕様書が作成されることで、チーム間でテスト方針を共有することができるようになります。また、このドキュメントは後のテストケース作成やテスト実施の土台となる資料です。

テスト仕様書との違い

テスト設計仕様書と類似した言葉にテスト仕様書がありますが、テスト仕様書は実際に実施するテストケースの詳細を記述することが目的です。テストの方針や範囲、観点を明確にするためのテスト設計仕様書とは目的が異なります。しかし、企業やプロジェクトによっては同じ意味で使われることもあるため注意が必要です。

テスト設計仕様書の項目

主な記載項目としては、以下のようなものがありますが、プロジェクトの性質によって異なる場合があります。下に挙げるのは、一般的な構成項目です。

• テストの目的と背景
  プロジェクトの状況や顧客のニーズを考慮し、テストに求められることを判断し、テストの指針を決定します。
• 識別子（ID）
  テスト設計仕様書の一意な識別子。
• テスト項目
  テストすべき具体的な内容（振る舞いや条件）を明確にしたもの。テスト対象の機能やコンポーネントが要求通りに動作するかを確認するための単位とも言えます。
• テスト設計のプロセス定義
  どのような手順やルールに従ってテスト項目を設計するかを明確にする部分です。
  テスト項目が作られた理由を明確にする部分となるので、チーム内で一貫した品質を保ったテストを行うことに役立ちます。
• 機能的要件・仕様の参照
  テストの根拠となる仕様書や要件定義書などのドキュメントへのリンクや参照。
• テストアプローチ
  どの部分をテストするのか、どのような内容のテストをするのかを定義し、テストを進めていく基本方針やテストケースの優先順位を明確にします。
• テスト条件
  テストを行うための入力条件や初期状態
• テスト入力データ
  実行に必要な入力値のリスト
• 期待結果
  テストケース実行後に期待される出力や動作
• テスト実行手順
  テストの手順が複雑な場合、手順を明記する（手動テストの場合に重要）。
• カバレッジ項目
  仕様や要件のどの部分をテストによってカバーするか
• 依存関係・前提条件
  テスト実施に必要な事前条件や依存関係（例：APIが動作している必要がある）。
• その他の補足事項
  テスト環境、制約事項、想定されるリスクなど。テスト実施の段階になって足りないものがないように準備を整えます。
  事前の動作確認や必要であればトレーニングについてもこの部分で記載されます。

テストアプローチ作成の流れ

テストアプローチを明確にすれば、テストの全体的な方針や戦略が具体的になり、関係者間で共通理解を得やすくなります。テストアプローチの項目では以下の内容が記載されます。

①テスト対象機能の一覧

この部分では、テストで、システムやソフトウェアのどの部分をテストするか、を明確にします。具体的にはテスト対象となる機能や要素を列挙していきます。
テストの実施に備えて、テストする機能や要素を適切に分割していきます。例えば、システムは、サブシステムや機能に分割することができますし、機能は、画面、状態、モジュールといった単位で分割することができます。ここでの分割は、テストの実施をしやすくするためのものなので、一番小さな単位で分割するというわけではないことを覚えておきましょう。あくまで、テストを実施しやすくするために機能を分割することを忘れないようにしましょう。また、分割する際には、開発資料などで定義されている分類や定義があれば、その用語を使って分割するようにすれば、関係者間での混乱を避けることができます。

②テスト観点一覧

まずテスト観点とは、テスト対象（システム、機能、画面など）をどのような視点でテストするかを整理・定義したものです。「何を確認するのか？」という視点を明確にして、漏れのないテストケースを作成するための指針とも言えます。
では、どのようにすれば漏れのないテスト観点を抽出することができるでしょうか。参考になるのは、あらかじめ組織で定められたシステム全般に対する観点一覧や過去プロジェクトの資産です。これらは、すでに関係者間で合意がとれている観点となるため、テスト観点を抽出するときに大いに役立ちます。しかし、これらに頼り切りになると、対象のシステム固有の観点を見逃してしまうことがあり得ます。これを防ぐために、テスト対象の分析を行い、それをもとにした観点を作成することも役立つでしょう。過去に発生した不具合を防ぐような観点を加えることも有効です。

③テスト技法の選定

この部分は、どのテスト技法をどのような基準で選択したのかを明確に記述します。まず、テスト技法を選定する目的と選定基準を記述します。そして、選定されたテスト技法を一覧にし、各テスト技法の適用範囲と選定理由を書きます。最後に選定しなかったテスト技法について、選定されなかった理由を記載します。

④テストレベルと種類の指定

この部分では、どのレベル（単体テスト、結合テスト、システムテストなど）で、どの種類のテスト（機能テスト、性能テスト、セキュリティテストなど）を実施するかを定義します。テスト技法の選定の時と同じように、まずテストレベルごとの目的を記載します。そして、テストレベルの定義として、各テストレベルの概要を記述し、対象機能・範囲を示します。その後、テスト種類の指定として、各テストレベルごとに、実施するテストの種類を明確に記載します。最後に、実施しないテストレベルや種類がある場合、その理由を記載します。

⑤重要度の決定とリスクの評価　

まず重要度とは、テスト対象となる機能やテスト観点をどれほど重点的に検証するかを定めたものです。テスト方針や重点項目に応じて重要度を決定していきます。通常は、テストの計画段階で大枠の機能については重要度が決定されていることが多く、その定義をそのまま引き継ぐことが多いです。どんな機能が重要かわかればテストのためのリソースを有効に活用していくことが可能になります。
リスクの評価については、「発生確率」と「影響度」を掛け合わせて算出されます。より詳しく、リスクの評価をする際は、発生確率と影響度をそれぞれ「低・中・高」の3段階または「1〜5」の5段階で評価し、これらをかけ合わせたものをリスクレベルとして数値化し、重要度の基準とします。

発生確率	影響度	リスクレベル	優先度
低	低	1	低
低	中	2	中
低	高	3	中

⑥テスト環境と制約条件

ここでのテスト環境とは、テストを行うための ハードウェア、ソフトウェア、ネットワーク設定、データベース構成、ツールなどの組み合わせ を指します。また、制約条件とは、テスト実施時に 考慮しなければならない技術的、運用的、スケジュール的な制約 を指します。これらの情報を記載しておくなら、後々のリスク管理も容易になります。

テスト設計仕様書を作成するときの注意

ここでは、テスト設計仕様書を作成するときに全体的に気をつけておきたいポイントを紹介します。

・追跡性・関連性をもたせる

ここでの追跡性・関連性とは、テスト設計仕様書をみることで、作成時に前提となった開発仕様書や上位ドキュメント、または作成時に参照した関連ドキュメントがどのドキュメントであるかを識別できるという意味です。テスト設計仕様書で追跡性・関連性が保たれていれば、要件がすべてテストされているかを網羅的に確認できますし、要件の変更がどのテストケースや不具合に影響を与えるかを迅速に特定できます。また、不具合の発生源の特定を効率化することにも役立ちます。

・定義の理由を記述する

テスト設計仕様書を作成する際、テストに関する様々な事項の定義を記載することになります。そのとき、各定義に「なぜそのように定義したのか」の理由を記載するようにします。定義の理由をしっかりと記載するようにすれば、定義の内容が曖昧なものを発見できたり、なぜそのテストが必要なのかを理解することができるようになります。理由を記載するようにすることで誤解や認識のズレを防ぐことができるようになります。
テスト設計仕様書そのものにはっきりと各事項の定義が記載されていれば、テストケースの作成者などの第三者がテスト設計仕様書を理解することを助けることができます。また、テスターも、疑問が生じたときにテスト設計仕様書からその疑問を解決することが容易になります。そして、レビューの際も、定義についての質問を減らすことができるので効率的に進めることができるようになります。

・記述の粒度に配慮する

記述の粒度とは、記述内容の詳しさ、細かさのことです。度が適切でないと、テスト設計仕様書の品質や活用効果が大きく損なわれます。そこで、テスト設計仕様書を作成する際は読み手の理解度を考慮して、粒度を調整するようにしましょう。あまりにも細かいと、情報量が多くなり、読み手が疲弊してしまいます。また、重要なポイントが埋もれてしまい、肝心のテスト意図が伝わりにくくなってしまうことでしょう。逆に、粒度があまりにあらいと、テスト手順が曖昧になり、実行者ごとに解釈が異なってしまうことがありえますし、テスト結果の再現性が確保できないことがあるでしょう。

テスト設計仕様書の使い方

テスト設計仕様書は、テストの目的や観点を定めるものです。この部分では、テスト設計仕様書がどのような場面で役立つのかを紹介します。

・各関係者との情報共有

テスト設計仕様書の活用方法の一つは関係者(ステークホルダー)との情報共有です。今から実施するテストがシステムの要求やテストへの要求にかなったものかを確認することができます。つまり、テストの方向性を関係者間で共通の認識とすることで、大幅な手戻りなどを防ぐことができるようになります。
テスト設計仕様書があれば、テスト範囲とカバレッジを、テストケース作成の前に確認することができ、関係者間でどこまでテストするのかということを共通の認識とすることができます。また、何をもって合格とするのかを決めておくこともできるため、バグの認識相違を防ぎ、品質基準の一貫性を保つことができるようになります。

・テスト設計の管理がしやすくなる

テストは複数人のチームで行うことが大半です。それで、テスト設計仕様書がないと、テストの方針がずれたばらばらのテストケースが作成されてしまいかねません。テスト設計仕様書に従うことで、テストプロセスを統一し、一貫性のあるテスト手順を確立することができるようになります。また、テスト設計仕様書には各テストケースの優先度やリスクレベルが明示されるため、リソースを重点的に配分できます。これにより、重要度の高いテストケースを効率的に実行でき、無駄なテストの実施を避けられます。
また、設計作業開始後も、テスト設計仕様書と開発仕様書をリンクさせておくなら、トレーサビリティをとる資料としても活用できます。仕様変更時には、関係するテストケースを洗い出すことができるので、抜け漏れを防ぐことができるようになります。

・テスト実施が効率的になる

テスト設計仕様書を活用すれば、テストの進捗管理を効率化することができます。テスト設計仕様書を参照すれば、どのテストケースが完了しているのか、どのテストが未完了なのかを迅速に把握できるようになるからです。また、テスト設計仕様書の内容をテスターがよく把握しているなら、ただテストケースに書かれていることを確認するだけでなく、テストケースの作成意図をくみとったり、確認する部分の周辺にも気をくばることができ、品質の向上に役立てることができます。

・リリース後の保守・開発資産になる

リリース後に保守または派生開発を行うときに必ず必要となるのが回帰テストです。付け加えた修正によって、既存のシステムに影響が受けていないかを確認するために回帰テストが行われますが、テスト設計仕様書には過去のテストケースが網羅的に記載されているため、新規のテストケースを作成せずに迅速に回帰テストを実施することができます。特に、自動化テストの設計にも再利用可能であることは覚えておきましょう。

テスト仕様書とは

上記のように、テスト設計仕様書が作られていくと、テストの目的や観点が整理され、どのようなテストを行うかが具体的になっていきます。このテスト設計仕様書を詳細化していく形でテスト仕様書が作成されます。
テスト仕様書では、個々のテストケースを具体的な手順とデータで記載します。つまり、ソフトウェアテストをどのように行うかを具体的にまとめたものです。このドキュメントの主な目的は、バグや不具合を検出して品質を確保することと、必要な機能が正しく実装されているかを確かめる要件の検証です。また、だれがテストをしても同じ結果が得られるようにする再現性の確保も目的の一つです。
次の部分では、テストケースの書き方について紹介します。

テストケースの書き方

テストケースには以下のような項目が記載されます。

以下では、上記のテストケースの項目から主要なものについて紹介していきます。

・テスト対象

テストするべき対象を記載します。何をテストするのかを明確にします。テスト対象となる具体的な機能や画面、もしくはシナリオについて書きます。テストを円滑に進めるために、どのようにテスト対象を分割するのかが良いかを考慮していきます。

・テスト観点

テストで確認したいことを記載します。どのような視点や観点でテストをするのかを明確にしておきます。テスト観点としては、様々なものがあります。例えば、仕様通りの入力や操作で、機能が正常に動作するかを確認する正常系、無効な入力や不正な操作でエラーが適切に処理されるか確認する異常系、入力データの境界値や限界値での動作を確認する境界値など様々です。プロジェクトに必要なテスト観点を設定する必要があります。

・テスト条件

テストを実行する前の条件を定義します。テスト実施前に条件を定めておけば、テストが再現可能になり、期待値の検証を確実に行うことができます。テスト条件として、具体的なものをあげると、前提条件(テストを開始する前に設定しておくべき状態やデータ)、入力データ(またはデータセット)、システム状態、環境設定などが挙げられます。

・テスト手順

テストで確認したい結果が表示されるまでの確認手順。手順を具体的に記載し、テストの再現性を確保します。手順が詳細に記載されていればテスター間での認識のズレを防ぐことができるので、操作ミスによる漏れを防ぎ、不具合の検出率もあげることができます。
各手順は一つのアクションに限定して具体的かつ詳細に書きましょう。また、入力データや期待値も明確に記載します。そして、例外処理や分岐条件についても忘れずに記載するようにしましょう。

・期待値

どのような結果になれば合格か、テストを実施した際に期待される結果を記載する。テスト結果は判定する基準となるので明確かつ具体的に書くようにしましょう。
各操作ごとに期待値を決めておくことが望ましいです。テストに漏れがないよう、正常系、異常系、境界値は確認するようにしましょう。検証するテスト観点ごとにも期待値を設定しておくようにします。

テストケースを作成する時のポイント

テストケースは、どのようなテストを実施するかを明確に示す必要があります。テスター、ほかのテスト設計者、レビュアー、開発者など様々な人が読むことを考慮して作成していくことが重要です。ここからは、テストケースを作成する際に気を付けておきたいポイントを3つ紹介します。

・再現性を重視する

テストケースを作成するときには、何を確認するためのテストなのか明確にわかるようにしておきましょう。テスト観点、確認内容の部分で、そのテストで何を確認したいのかが読み手に伝わるように配慮しましょう。そうすれば、どんな人が行っても同じテスト結果を得られる再現性を確保することができます。
テストケースに再現性の確保が重要であるのは、バグの正確な検出と修正が可能になるからです。再現性のあるテストケースであれば、バグが発生した際に 確実に同じ結果を再現することができます。このおかげで、開発者が同じ入力データと手順で実行することで、バグの原因特定と修正が容易になります。

・期待値を具体的に記述する

テストケースを作成するときに、期待値を具体的に記述することは大切です。「処理が正しい」や「正しく動作する」などの曖昧な表現は避けるようにしましょう。何が正しい結果なのか明確に記載するようにしましょう。特に、項目名やデータの内容は詳しく書くように心がけましょう。期待値が具体的でないと、 そのテストケースの意図が不明確 になり、仕様の誤解が生まれてしまいます。結果として、テスターがテスト結果NGとして報告されるべきものをOKと判定して、不具合を見逃してしまう可能性があります。

・網羅性を確保する

テストケースを作成するときに、網羅性を確保することは、品質の高いソフトウェアやシステムを提供する点で欠かせないプロセスだといえます。様々な理由がありますが、例えば、網羅性を確保することで、特定の入力パターンや境界値などがテスト対象から漏れてしまうことを防ぐことができるので、見逃しやすいバグを確実に検出できるようになります。また、テストケースの網羅性を確保することで、 コードの各部分が確実に実行されるようになります。これにより、コード内の 未実行部分（デッドコード）を発見することもできるようになります。
網羅性の高いテストケースを作成できれば、ユーザーのさまざまな使用パターンに対応したソフトウェアを提供することができます。例えば、「会員登録済みのユーザーであれば、会員限定ページにアクセスできる」という機能をテストするときは、「未登録ユーザーであれば、会員限定ページにアクセスできない」ということもテストしなければならないのではないかと考えることができます。このように、ユーザーがどのように使用するかに配慮できれば、仕様への考慮漏れや仕様書への記載不足などを指摘することができ、品質の向上に役立てることができます。

まとめ

今回はテスト設計仕様書とテスト仕様書について紹介しました。テスト設計仕様書はソフトウェアやシステムのどの部分をどのようにテストするか、テストの方針を明確にするためのドキュメントです。一方、テスト仕様書は、テスト設計仕様書を詳細化する形で作成され、どのようなテストを行うかを具体的に記載するもので、テストケースという形で記載されます。どちらのドキュメントも、テストの精度に大きく関わり、ソフトウェアやシステムの品質を高めることに貢献するドキュメントです。

お問い合わせはこちら