はじめまして。

今回このブログを書かせていただきます、
ヒューマンクレストの高橋です。

私の担当する回ではテストに関するTipsをいろいろ書いてみようと思います。

第一回目としてはテスト設計にスコープを充ててみました。
題して「テスト要求仕様をきっちり書いてみよう！！」です。

今までの私の経験では、テスト要求仕様をきっちり書く事はあまりしてなくて、
プロダクトの要求仕様の整理とこんなテストをやるっていう程度の、
ざっくりとしたものしか作っていませんでした。

そのざっくりしたテスト要求仕様からテストケースを起こす事は、
テストケース作成行程で仕様について再度調査が必要になったりと、結構工数を要してしまった経験が多々有りました。

そこで、テスト要求仕様の作成段階からきっちりと詳細を詰めていこうという結論に至りました。

もちろん、テスト設計にインプットすべきプロダクトの要求仕様ができていない
といった事情も有ると思います。
その場合は、開発者側へ仕様書提供の訴求を並行して実施し、現状ある情報でテスト要求仕様を作成をしています。
（まあそれしかできませんが。）
後で入手できた要求仕様に関する情報をプロットしていくだけなので、
そんなに手間がかかることはないと思います。

あらかじめ、体系的にテスト要求仕様がまとめられていれば、
テストケースを作成するときに、テスト実行時に必要なテスト実行手順と
それに付随する各種（入力時、出力時）のパラメータを変更していくだけでよく、
テストケースの作成がスムーズに、より少ない工数で行えます。

では、テスト要求仕様書にどのような項目を用意すれば良いでしょうか。

テストを円滑に実施する為の有効なテストケース
（※できる限り多くのエラーを検出して品質を保証できるケース）
をスムーズに作るために、テスト要求仕様書で明確にしておくべき項目
を洗い出してみました。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

前提

「テスト計画→テスト設計→テスト実行」の流れで記載しています。
.テスト設計の主なタスクとして「テスト要求仕様書の策定」「テストケース仕様書の策定」を定義しています。今回主に記載しているのは「テスト要求仕様書の策定」です。
言葉の定義は以下の通りです。

ユースケース：利用者がシステム（もしくは機能）を使ってできることを表したもの。
テストケース：「この状態でこの入力を行えば、この処理が行われてこの結果が期待される」と言った内容を示すもの。ユースケースに基づいて作成されるもの。

テスト要求仕様書に必要な項目

1.テストスコープ

テストを実施する機能のスコープを定義します。
どこからどこまでがテストの範囲であるのかを明確にし、テストを行う範囲とテストを行わない部分を明確にします。（テスト実施に当たり制限事項が発生する場合は記載を行います。

2.テスト実行時の環境とテストツールの明確化

テストを実施する環境について明確に記載します。
またテスト実行時にツール（スタブなども含む）を必要とする場合も
ツールを使用する目的とツールを使用する機能について記載を行うようにします。
（ツールの仕様手順が記載された手順書を用意し、テスト要求仕様書とリンクできていると良いと思います。）

3.機能の概要の整理

要求仕様で定義されている機能の動作概要を記載し、機能ごとに正常動作と異常動作を明確に定義します。
上記を機能ごとに階層化して、大項目、中項目、小項目といった単位で処理概要を整理します。

4.ユースケースの洗い出し

3で整理した機能概要の整理より、想定しえるユースケースを洗い出します。
その際、洗い出したユースケースが正常系のユースケースであるのか、
異常系のユースケースであるのかを明確に記載しておきます。
またユースケースごとの前提条件（input）、処理（procedure）、期待値（output）を明確にしておきます。
ただし処理については細かいオペレーションについては記載せず、
概略だけで大丈夫です。
細かいオペレーションについてはテストケースで記載すれば問題なく、ユースケース単位でテストで実施したい事の流れが把握できればよいです。
（また処理について細かくすると、要求仕様の変更などでユースケースの修正が必要である場合に結構修正が細部に必要になってしまい修正の工数を要してしまいますので、概略が分かる程度で大丈夫です。）

5.使用するテスト技法を定義します。

ユースケースごとに使用するテスト技法
（ex:同値分割,境界値テスト、デシジョンテーブル、状態遷移テスト,シナリオテストetc）を定義していきます。
※テスト種類に着いては前行程であるテスト計画段階で定義されているという前提で、ここでは記載しません。

6.テストカバレッジの確認

機能と「ユースケースごとの確認したい内容」の概要を縦軸に設定し、要求仕様で記載されている機能の動作内容を横軸にプロットしたマトリクス図を用意します。
ユースケースが要求仕様で定義されている機能の各動作内容を網羅できているか、否かの確認（テストカバレッジの確認）を行います。

7.Inputドキュメントの整理

ここが結構重要で、テスト要求仕様書のInputになる設計書関連のドキュメントを明確にしておく必要が有ります。
何よりどの仕様書に基づいてテストを行っているのかということは明示しておく事は、追跡可能性（トレーサビリティ）を確保する為に、テストを行う上では
絶対に必要な情報になります。
また、仕様変更等が発生した際に、変更内容を確認してユースケースを修正する際に必要な情報になります。
ユースケースごとにInputとなっている設計書関連のドキュメントの記載箇所を明示しておくと、設計書とのリンクが
行え、6で挙げたテストカバレッジの確認時に有効です。

8.Outputドキュメントの定義

テスト要求仕様書のOutputになるドキュメント、つまりテストケース作成時に作成するドキュメントを定義しておき、テスト実行時に必要になるドキュメントを
定義しておきます。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

大きな項目では上記の8点になるでしょうか。

要は「準備できることは早めにやっておいた方が後で苦労する事は少なくなる」
という事になります。

みなさんも、もう一度、テスト要求仕様書を体系的にじっくり書いてみませんか。
結構、テストケースの作成が楽になりますよ！！
騙されたと思ってぜひ！！

次はテストケース作成時のTipsを書いていきたいと思います。

最後までご覧頂き、ありがとうございました。