はじめに
担当プロジェクトで単体テスト計画書をつくることがあったので、記載項目等を共有したいと思います。
これから単体テスト計画書を作成される方の参考になれば幸いです。
該当工程
単体テストは、「ソフトウェアレベルの単体テスト」と「機能レベルの単体テスト」に分かれます。
これらのテストは、実装作業と並行して行われることが多いので、「実装工程実行計画書」の中に含めて書かれる場合もあると思います。
この記事ではそれぞれ分けて記載しますので、プロジェクト特性に合わせるようにしてください。
ソフトウェア単体テスト
テストの目的
各ソフトウェア単体が詳細設計書で定義された仕様通りに動作することを検証する。
テスト範囲・テスト対象
※プロジェクトにおけるテスト対象範囲を記載してください。システム構成図があると分かりやすいです。
※また、詳細設計書の管理単位（詳細機能一覧）を列挙しておくと、進捗管理に使えます。
テスト観点
・エラーやログ出力などの共通詳細仕様について、仕様通りにソフトウェアが動作することを確認する。
・詳細設計書の個別詳細機能仕様について、仕様通りにソフトウェアが動作することを確認する。
テスト手法
・ホワイトボックステスト手法を用いて、詳細設計書の分岐を網羅するようにテストケースを設定する。
・テストケース設定においては、C1カバレッジが100%であることを確認する。（何かしらの理由によって実施できないものはその理由を明記する）
テスト環境
・各開発者のローカル環境にて検証を行う。
・また、テストデータはテスト条件を満たすデータを手作成する。
開始条件・完了条件
開始条件：
・テスト対象のソフトウェアについて、実装が完了していること。
・テスト対象のソフトウェアについて、テスト仕様書が完成していること。
完了条件：
・テスト対象のソフトウェアについて、テストケースが全て実施されていること。
・検出した不具合が全て解消されていること。
成果物
※顧客に納品が必要と定義されている成果物を列挙してください。
管理方針
進捗管理
・詳細機能毎にテストの予実を管理する。
（例： 8/12時点 予定5本に対して、実績4本 遅延1本。遅延1人日）
レビュー計画
※ソースコードレビュー、テスト仕様書レビュー、テスト結果レビュー等のレビュー予定を記載してください。
バグ管理
※バグ検出時のフローや管理項目を記載してください。
ソフトウェア単体テスト段階では起票しない（管理しない）プロジェクトもあるかと思います。
評価
※ソフトウェア単体テストでの品質指標（テスト密度やバグ密度）があれば、その数値に対しての良し悪しを評価します。
体制・役割
※プロジェクトの体制図をペタッと貼る
※基本的にベンダー側の作業になりますが、ベンダー内で詳細な役割分担がある場合はそれを明記しておく
※また、「実装者とテスト実施者は別の担当者とする」といったルールがある場合も記載しておく。
機能単体テスト
テストの目的
機能単体が基本設計書で定義された仕様通りに動作することを検証する。
テスト範囲・テスト対象
※プロジェクトにおけるテスト対象範囲を記載してください。システム構成図があると分かりやすいです。
※また、基本設計書の管理単位（詳細機能一覧）を列挙しておくと、進捗管理に使えます。
テスト観点
・基本設計書の個別機能仕様について、仕様通りに各機能が動作することを確認する。
※機能テストについては、TIS社が公表しているテスト観点カタログが素晴らしいので、ぜひ使ってみてください。
テスト手法
・ホワイトボックステスト手法を用いて、基本設計書の個別機能仕様を網羅するようにテストケースを設定する。
・テストケース設定においては、C1カバレッジが100%であることを確認する。（何かしらの理由によって実施できないものはその理由を明記する）
テスト環境
・各開発者のローカル環境にて検証を行う。
※テーブルは、プロジェクトで共通のスキーマを利用する場合もあると思います。
・また、テストデータはテスト条件を満たすデータを手作成する。
開始条件・完了条件
開始条件：
・テスト対象の機能について、ソフトウェア単体テストが完了していること。
・テスト対象の機能について、テスト仕様書が完成していること。
完了条件：
・テスト対象の機能について、テストケースが全て実施されていること。
・検出した不具合が全て解消されていること。
成果物
※顧客に納品が必要と定義されている成果物を列挙してください。
※顧客企業によりますが、単体テスト仕様書やテスト結果エビデンスなどが考えられます。
管理方針
進捗管理
・機能毎にテストの予実を管理する。
（例： 8/12時点 予定5本に対して、実績4本 遅延1本。遅延1人日）
レビュー計画
※テスト仕様書レビュー、テスト結果レビュー等のレビュー予定を記載してください。
バグ管理
※バグ検出時のフローや管理項目を記載してください。
※機能単体テスト段階では、ほぼ全てのプロジェクトでバグ管理をすると思います。
評価
※機能単体テストでの品質指標（テスト密度やバグ密度）があれば、その数値に対しての良し悪しを評価します。
体制・役割
※プロジェクトの体制図をペタッと貼る
※基本的にベンダー側の作業になりますが、ベンダー内で詳細な役割分担がある場合はそれを明記しておく
※また、「実装者とテスト実施者は別の担当者とする」といったルールがある場合も記載しておく。
おわりに
単体テスト計画書の記載事項について整理してきました。
小規模なプロジェクトであれば、こういった計画書は不要かもしれませんが、ある程度の規模を超えてくるとプロジェクト関係者の共通認識を持って進めるためには計画書が必要になると思います。