SEとして経験を積み、いくつものプロジェクトに参画すると、現場やチームによって作られる資料のフォーマットが全く違うことに困惑した経験はないでしょうか。同じ企業内でさえ、案件によっては何もかも書き方が違うことも少なくありません。
特にテスト仕様書やそのエビデンスがバラバラだと、非常に困りますよね。どんなスタイルが正解か、というのは一概には言えず、どんなやり方にも一長一短のメリット・デメリットが存在します。
では、どんなスタイルで書くのが最も効率的なのでしょうか。
筆者が実際に担当したテスト仕様書の中から、特徴的なものをいくつかピックアップし、比較してみました。

シナリオ考案型

テスト仕様書の記載時に、担当者自身が必要なテストシナリオを一つ一つ考えて記述していく形式です。どちらかと言うと、結合テストに近いやり方と言えるかも知れません。
このスタイルのメリットは、業務フローを意識したテスト項目を作れる点です。仕様レベルのバグを発見しやすく、致命的な仕様ミスを潰していけるのは良いですね。
逆にデメリットとなる点は、担当者の理解が不足していると、必要なテストパターンが漏れる可能性があるというところです。まず仕様書を良く読んでから、テスト項目を作るよう気を付けましょう。

マトリクス網羅型

プログラムが利用するであろう、あらゆるデータパターンをマトリクス化し、全ての組み合わせでテストケースを作るというものです。エクセルに膨大なデータパターンが記載されるのは、ある種壮観な光景と言えるでしょう。
メリットはもちろん、あらゆる組み合わせを想定したテストの網羅率の高さです。
デメリットは、テスト仕様書の作成と、テスト実施の工数が跳ね上がる点にあります。また、あまりに巨大な表になり過ぎると、テスト結果を可読性が落ち、非常に読みにくくなることも挙げられます。

設計書利用型

やや特殊な方法ですが、設計書をそのままテスト仕様書として扱うスタイルも存在します。実際の設計書をコピーし、欄外にデータパターンを記載し、ロジックごとにテストを行う形式です。
最小限の工数でかなりの網羅率を実現できる点は大きなメリットなのですが、クライアントによっては「テスト仕様書作成をサボっているのでは」などと思われ、拒否反応を起こされることがあります。この点だけは、最大のデメリットと言えるでしょう。

オススメは「設計書利用型」

様々なテスト仕様書を作成してきた筆者ですが、最も効率的に感じたのは最後の「設計書利用型」のスタイルです。設計書を作成する段階でテストケースのことも考えることが出来るので、他とは比べ物にならない能率を実現できます。
難点はクライアントの反応のみなので、要件定義の時にテスト仕様書の書き方についても詰めておき、少しでも工数を削減できるようにしてみてくださいね。