2. テスト仕様書
今回の連載「テンプレートから学ぶ 受注する開発者のためのテスト仕様書」では、開発側の立場から現場で必要なテスト仕様書を解説します。
- いつ、誰が、どういうテスト仕様（テスト仕様と言ってもたくさんあります）を、どういう風に書いたらよいか
- 何に注意しないといけないのか（現場のコツのようなもの）
- どこまでテストすれば良いのか（テスト完了条件）
- 単体テストの場合
- 統合テストの場合
- 要件仕様がない場合どうテストするのか
- 仕様変更がプロジェクト後半に発生した場合、どうテストするのか
今回は第1回目なので、最後にテスト仕様の目次を掲載します。
2.1. テスト仕様の種類
開発者が書く必要のあるテスト仕様は以下の2種類です。
- 単体テスト仕様
- 統合テスト仕様
2.2. いつ書くか
2.2.A. 単体テスト仕様
単体テスト仕様はプログラミングの直前に書きます。つまり最後の設計局面（プロジェクトによって「詳細設計」「内部設計」などと呼ばれます）の局面終了基準の中に単体テスト計画を含めます。
2.2.B. 統合テスト仕様
統合テストをひとまとまりの文書として記述する場合、統合テスト仕様は最初の設計の直前（プロジェクトによって「基本設計」「外部設計」などと呼ばれます）に書きます。つまり、要件定義局面の局面終了基準の中に統合テスト計画を含めます。
統合テストは、次の2つの設計局面に分けて、2つの文書を作成することもあります。
- 外部設計（または基本設計）
- 内部設計（または詳細設計）
2.3. 誰が書くか
図2に開発組織を示しました。破線の中が発注者で、外側に受注者を描いています。大きなプロジェクトだと「プロジェクト推進」というグループを設けます。これは個々の開発チームを横断的に支援するグループで以下を提供したり管理したりします。
- 開発技法
- 開発ツール
- プロジェクト管理支援
- 局面終了基準管理
- プロジェクト報告
「基盤」グループを設けることもあります。これも開発チームを横断的に支援しますが、以下を提供したり管理支援したりします。
- ハードウェア
- ネットワーク
- 共通ソフトウェア
- OS
- 実行環境
- 開発環境
2.3.A. 単体テスト仕様
「単体テスト仕様」は、発注者のプロジェクト推進がメーカーのSE（受注者）の助けを借りて作成します。単体テストを実際に行うのはプログラムを作った人、つまり、開発者です。
テスト結果は開発者が起票し、お客様に提出します（開発No. 1……No. n）。開発No. 1……No. nは、結果をプロジェクト推進に渡します。プロジェクト推進は、テスト期間中なら朝会（あさかい）または夕会（ゆうかい）で、プロジェクト・マネージャおよびプロジェクト・リーダー達に報告します。局面終了時なら、プロジェクト・マネージャが局面終了報告書をとりまとめますが、その中にちゃんとテストしましたと書くことになります。
2.3.B. 統合テスト仕様
「統合テスト仕様」は、発注者のプロジェクト推進がメーカーのSE（受注者）の助けを借りて作成します。統合テストを実際に行うのは開発グループ（開発No. 1……No. n）で、メーカーの開発者の助けを借りて行います。
テスト結果はメーカーの助けを借りて開発グループが起票し、プロジェクト推進に渡します。プロジェクト推進は、テスト期間中なら朝会（あさかい）または夕会（ゆうかい）で、プロジェクト・マネージャおよびプロジェクト・リーダー達に報告します。局面終了時なら、プロジェクト・マネージャが局面終了報告書をとりまとめますが、その中にちゃんとテストしましたと書くことになります。
2.4. どういうテスト仕様を書くか
テスト仕様では、「目標」「方法」「実際の手順」「結果」「品質が悪いことが分かった時の対処方法」など、実にさまざまなことが文書になっていなければなりません。今回は下記のテンプレートを用意しておくことになります。
2.4.A. 単体テスト仕様
単体テスト仕様でのテスト技法は以下の3点です。
- ホワイトボックステスト
- ブラックボックステスト
- 信頼度成長曲線
これらの技法は、それぞれの観点で「ちゃんとテストしました」と言うためのテストです（次回以降に詳しく述べます）。
2.4.B. 統合テスト仕様
統合テスト仕様でのテスト技法は以下の5点です。
- トランザクション・フロー・テスト
- ドメイン・テスト
- 例外系テスト
- 基盤テスト
- 対象システムの連結テスト
これらの技法は、それぞれの観点で「つないでテストしました」と言うためのテストです（次回以降に詳しく述べます）。
