2024.02.07
テスト設計仕様書は、テスト基本設計プロセスのoutput（成果物）として位置付けられています。
テスト設計仕様書の主な目的は、主に下記の2点です。
- どの部分をテストするのか
- どのような内容のテストをするのか
そのテスト対象の全体を見据え、上記を明確化し、テストの指針や骨格を定めることにあります。
本記事では、テスト設計仕様書の各項目と使い方、作成時の注意点について解説していきます。
- もくじ
1．テスト設計仕様書とは
テスト設計仕様書とは、上述のとおり、そのテスト対象の全体を見据えて、テストの指針や骨格を定めることです。文字どおり、テスト設計のための「仕様書」となります。
テスト設計仕様書の主要な項目には、以下があります。
- テストの目的と背景、重点テスト項目
- テスト設計のプロセス定義
- テストアプローチ（テスト対象機能一覧、テスト観点一覧）
- テスト環境・使用機材
上記がすべてではなく、テストプロジェクトに応じて必要な項目は追加、変更が発生することもあります。各項目の詳しい説明は、本解説コンテンツ中の別の章で記載します。
テスト設計仕様書は、テスト計画書を基に作成します。
規模が大きいプロジェクトでは、テスト設計仕様書を分冊して作成することもあります。
機能テストやシナリオテストなど、テストタイプごとにテスト設計仕様書を分けて作成することもあります。
それでは、テスト設計仕様書の各項目の内容を以降で説明します。
2．テスト設計仕様書の各項目
テストの目的と背景、重要テスト項目
実施するテストの目的と、その背景、重要テスト項目などを整理します。基本的にはテスト計画書の段階で整理されている項目であり、テスト設計仕様書の記載範囲に合わせて再度確認します。
ここで念頭に置くべき大切なことは、機能仕様書等を単になぞるようなテストでは不十分なことが多い、ということです。
開発プロジェクトの状況や、テストの実施を依頼している方の要望等を分析し、テストに求められていること（テストへの要求）を的確に把握し、それを基にテストの指針を定めることが大切です。
テスト設計のプロセス定義
テスト設計工程の手順をここに記載します。QUINTEEでは、このサイトで解説している一連の内容を記載します。
QUINTEEといったように、テストのプロセスや工程は、その組織ごとに標準的なものが定義されていることも多いことでしょう。しかし、プロジェクトごとに標準的なテストプロセスベースにカスタマイズしていることもあるでしょうし、独自で工夫をしたプロセスを追加していることも十分にあり得ます。
これらを文書化して関係者と共有するのが、本項目の目的です。
テスト設計の流れを文書化しておけば、テストチームに新たに参画するメンバーが状況を把握しやすくなりますし、テストチーム以外のステークホルダーに、テストのプロセスを説明するのにも役立ちます。
テストアプローチ
テスト設計仕様書でもっとも重要な部分です。
テストアプローチでは、「どの部分をテストするのか」「どのような内容のテストをするのか」を検討し、定義していきます。具体的には以下の内容を作成していきます。
- テスト対象機能（要素）一覧
- テスト観点一覧
詳しくは次の項目「テストアプローチ作成の流れ」で解説します。
テスト環境・使用機材
テストに必要な環境や使用機材などをここで整理しておきます。テストを実施する段階になって、必要な機材などが足りなくなってしまった、などということがないように、予め整理しておきます。
機材の調達、テスト環境のセットアップ、事前の動作確認、必要であればトレーニングなど、付帯するタスクも洗い出し、テスト実施時にはすべて準備が済んで滞りなくテストが実施できるように計画しておくことも必要です。
3．テストアプローチ作成の流れ
テスト対象機能(要素)一覧
テスト設計の中でも重要なのが、「どの部分をテストするのか」ということです。ソフトウェアによっては「機能」という表現を使用せず、「フィーチャー」などと概念的に記載することもあります。また、機能ではなく画面単位や状態単位で分けられることもあります。そういった場合も含めてここでは「テスト対象機能（要素）」と表現しています。
ここからは、機能テストについて具体的に解説していきます。機能テストの場合、その機能、つまり「どの部分をテストするのか」という部分を適切に分割していきます。「適切に」というのは「テストが設計、実施しやすいように」という意味です。
ソフトウェアは「システム」という大きな分類から、たとえば「サブシステム」や「機能」といった形に分割されていくことが一般的です。さらに、機能は「画面」や「状態」や「モジュール」といった単位で分割されることがあります。分割ができるから、あるいは開発仕様書でそのように定義されているから、といった理由で、細かすぎる分類をそのままテストで使用することは、かえってテストの全体像が分かりにくくなり、テストの抜け漏れにつながってしまうため、適切な規模でまとめていくことがポイントです。
また、開発資料で定義された分類や定義があるのであれば、それをもとに考えるようにするといいでしょう。テスト設計者が独自の用語を使用してしまうと、それはどういう意味なのか、ということを考えたり、すり合わせたりする必要が生じ、二度手間となります。
テスト観点一覧
テスト対象の機能が整理できたら、次はテスト観点を考えます。
テスト観点とは
テスト観点とは、「どのような内容のテストを実施するのか」というものを表した、いわば「テストの切り口」のようなものです。たとえば、画面のテストを実施する場合は、どのような画面であっても、「表示レイアウト」や「表示されている文字」についてはテストを行うことでしょう。また同様に、入力用のテキストボックスが存在する場合、「文字種」や「入力可能文字数」などといった点についてテストしていきます。このようなものを「テスト観点」と呼んでいます。
テスト観点の抽出
テスト対象機能と違って、テスト観点は幅広い考え方を含んでいます。このため、考慮できる観点を洗い出すのは難しいと思われるかもしれません。
テスト観点の抽出において、属人化を排除し、抽出漏れを防ぐためには、システム全般に対する観点一覧や、システムの対象ドメインに対する観点一覧をあらかじめ組織で作成しておき、それを参考にするといいでしょう。また、過去のプロジェクト資産を流用するのも効率的です。
ただし、それらに依存しすぎてしまうのも、そのシステム固有の観点を見落とす可能性があります。そのため、テスト対象の分析を合わせて行い、それをもとにした観点の作成が必要となります。過去のテストケースを抽象化して観点を洗い出す、過去に検出した不具合をもとにそれを見つけられるような観点を追加する、などの方法も有効です。
機能・観点の双方ともに言えることですが、あまり細分化を進めてしまうと、逆にテストの抜け漏れが発生しやすくなります。そのため、適度な抽象度での分割を行うことを心がける必要があります。逆に、抽象化しすぎて何を確認すればいいのか想像できないのもよくありません。さじ加減の難しいところですが、そういう場合は「テストがしやすいか」「全体を通して分かりやすいか」という観点で判断すればいいでしょう。
重要度の決定
ここまででテスト対象機能（要素）とテスト観点について解説してきました。
この後に、それぞれの重要度を設定していきます。重要度は、その機能及び観点をどれだけ重点的にやるかを定めたものです。テスト方針やテストの重点項目に応じて重要度を設定していく必要があります。
テスト計画段階で大枠の機能やテストタイプを検討するため、その段階で重要度を決定しておき、テスト設計仕様書作成時にはその方針を引き継いで分割していく形になるでしょう。
ただし、テスト計画で定義した重要度を機械的に引き継ぐのは妥当ではないこともあるので、注意が必要です。テスト計画段階での検討の粒度は大きいため、検討を進めたら重要度は見直しした方がよいことが分かることもあるからです。
そのような場合には、必要に応じてテスト計画まで戻って検討し直すこともあります。
4．テスト設計仕様書 作成時の注意点
ここまで、テスト設計仕様書の作成方法について、特に重要な部分を解説してきました。ここからは、作成時の注意事項を解説します。
テスト設計仕様書はテスト設計工程全体の品質を左右する
テスト設計仕様書は、具体的にどのようなテストをするのかを想像しながら、それに沿った内容にしましょう。
テスト設計仕様書は、以降のテスト設計プロセスの大元となるため、テスト設計仕様書の品質が悪いと、以降の設計すべてに影響してしまいます。
たとえば、テスト設計仕様書は、テスト設計ドキュメントであるテストマップや機能動作確認一覧の基になります。
誰が見ても分かりやすい記述、分類を心がける
テスト設計仕様書は、さまざまな用途でさまざまな者が参照するものです。このため、他の人が見て理解しやすい記載を心がける必要があります。
このことはテスト設計仕様書に限らず、他のドキュメントにも言えることです。
テストドキュメントは自分が分かりさえすればそれでよいものではありません。自分以外の他者でも使われることを念頭において作成するようにしましょう。
5．テスト設計仕様書の使い方
先に解説したとおり、テスト設計仕様書は、そのテスト対象の全体を見据えて、テストの指針や骨格を定めることです。
これを踏まえて、テスト設計仕様書の使い方と、そのメリットを見ていきましょう。
ステークホルダーへの情報共有
今から実施しようとしているテストが「システムへの要求」や「テストへの要求」と合致しているかを確認することができます。
それを関係者（ステークホルダー）と共有することによって、テストプロジェクトが誤った方向に進んでしまうことを防ぎます。
テストケースまで作成した段階で、求められていることと齟齬があることが分かったとしたら、大きな手戻りが生じてしまいます。テストの早期の段階でテスト設計書を通じて指針を確認することで、軌道修正が早期に図れ、プロジェクトの安定化に繋がることになります。
よって、特にテスト設計仕様書を作成する段階では、さまざまな項目を調査、検討し、場合によっては関係者にヒアリングをしたり、調整したりすることも必要です。
テスト設計の統制と効率化
テストプロジェクトは複数人のチームで実施することがほとんどです。その場合、ばらばらにテスト設計を進めていくと方針がずれてしまうことがあります。あらかじめ、テスト設計プロセスの早い段階で方針を確認するために、テスト設計仕様書が一役買うことになります。
また、設計作業開始後にも、テストケースと開発仕様書とのトレーサビリティを取る資料として活用できます。そのため、仕様変更が発生した場合でもテスト設計仕様書を参照することで、適切にテストケースを修正することができます。
テスト実施の効率化
テスト設計仕様書をテスト実施者が確認することも非常に有効です。なぜなら、テスト全体の方向性やテストの目的などを知ることにより、テストケースに書かれていることをただ確認するだけではなく、テストケースの作成意図を汲み取ったり、確認する部分の周辺にも気を配ったりしながらテスト実施ができるからです。
リリース後の開発資産として活用
リリース後の保守や派生開発を行うときには、作成したテストケースのどの部分を流用すればいいのかの取捨選択が必要となります。テストの全体を整理したテスト設計仕様書があればそれが容易になります。
まとめ
ここまで、テスト設計仕様書の作成について解説してきました。
テスト設計仕様書で検討した内容を起点とし、このあとのテストケース作成までの作業を続けていくことになります。丁寧に作成することを心がけましょう。
