コンテンツにスキップ

5. テスト仕様の書き方ガイド

このドキュメントは、テンプレート/04_テスト仕様書テンプレート/ 配下にある各種テンプレートを使用して、 プロジェクトのテスト仕様を記述するための具体的な方法とベストプラクティスを解説します。

1. 基本的な考え方

テスト仕様書は、開発した機能の品質を「どのように保証するか」を定義する、品質保証活動の計画書です。 良いテスト仕様書は、以下の目的を果たします。

  • テストの網羅性を可視化する: 何をテストし、何をテストしないのかを明確にします。
  • トレーサビリティを確保する: 各テストが、どの要求やユースケースを検証するためのものなのかを明確に結びつけます。
  • 非技術者との合意形成: 開発者以外(QA、POなど)もレビューに参加し、ビジネス要件が正しく検証されているかを確認できます。

「テスト規定」との違い

ドキュメント 目的 対象物
テスト規定 「テストコード」の書き方のルールを定める ソースコード (.cs, .ts)
テスト仕様書 「何をテストするか」の計画を定める ドキュメント (.md)

開発者は、まずこのガイドに従って「テスト仕様書」を作成し、その仕様書と「テスト規定」の両方を参照しながら「テストコード」を実装します。

2. テンプレートの使い分け

テストは、その目的とスコープに応じて複数のレベルに分かれます。テスト対象に応じて、適切なテンプレートを選択してください。

テンプレート名 テストレベル 主な目的 いつ書くか?
01_単体テスト仕様書テンプレート.md 単体テスト クラスやメソッド単体の振る舞いを検証する 開発者が実装と並行して
02_統合テスト仕様書テンプレート.md 統合テスト 複数コンポーネントや外部システムとの連携を検証する 機能実装後
03_E2Eテスト仕様書テンプレート.md E2Eテスト ユーザー視点での業務フロー全体を検証する 機能実装後、UIがある場合
04_性能テスト仕様書テンプレート.md 性能テスト 応答時間やスループットが要件を満たすか検証する 非機能要件に性能目標がある場合

3. 良いテストケースを設計するための観点

各テンプレートの「テストケース」セクションを記述する際は、以下の観点を考慮することで、網羅性の高いテストを設計できます。

  • 正常系 (ハッピーパス):
    • 最も一般的で、エラーが発生しない、想定通りの操作が行われた場合のシナリオ。
  • 異常系 (例外フロー):
    • 想定されるエラーが発生するシナリオ。
    • 例: 不正な入力値、権限不足、外部APIからのエラー応答、データベース接続断など。
  • 境界値:
    • 仕様の境界となる値を使ったシナリオ。バグが潜みやすいポイントです。
    • 例:
      • 数値: 0, 負の値, 最大値, 最小値
      • 文字列: 空文字列, null, 最大長, 特殊文字
      • 配列: 空の配列, 1要素のみの配列

4. トレーサビリティの確保

テスト仕様書は、要求と実装をつなぐ重要な役割を果たします。

  • 関連要件/ユースケース:
    • 各テストケースやシナリオが、どの要求ID (FUNC-..., SEC-...など) やユースケースID (UC...) を検証するためのものなのかを、必ずリンク付きで明記してください。
  • テストコードとの連携:
    • テストコードの実装側では、対応するテスト仕様書のケースID (TC-...) をコメントとして記載することを推奨します。これにより、コードと仕様書の相互追跡が可能になります。

例 (テスト仕様書):

- **関連要件:** `[FUNC-AUTH-1-1](../../../01_システム仕様/01_機能要件.md#FUNC-AUTH-1-1)`

例 (テストコード):

// ケースID: TC-AUTH-001
[Fact]
public void Login_WithValidCredentials_ShouldSucceed()
{
    // ...
}