テスト方針・計画

目的: システム全体のテスト戦略を定義し、品質目標を達成するための具体的なテスト方針と計画を明確にすることで、開発チーム全体が一貫した品質保証活動を実施する
スコープ: テスト戦略、テストレベル（単体・結合・システム・受入）、テスト観点、カバレッジ基準、スケジュール、体制をカバーする。個別のテストケースの詳細は対象外
推奨する実施タイミング: 基本設計の中盤から後半、システム構成やインターフェースが明確になった段階で実施する
関連するステークホルダー: テストマネージャー、品質保証チーム、開発チーム、プロジェクトマネージャー

📥 重要な前提知識・インプット

前提知識: テスト設計技法（同値分割、境界値分析など）、テストレベルの違い、カバレッジの概念、品質保証の基礎
インプット: 要件定義書、基本設計書（システム構成、データフロー、インターフェース仕様）、非機能要件一覧、品質目標

📄 成果物の定義

ドキュメントテンプレート: 📄[テンプレ]テスト方針計画書
必須要素: テスト方針書、テスト計画書、テストレベル定義、カバレッジ基準、テスト体制図、テストスケジュール

✅ 品質基準・レビュー観点

✅ 品質チェックリスト:

チェック項目	チェック内容
テスト戦略の妥当性	品質目標を達成できるテスト戦略が定義されている
カバレッジ基準の明確性	各テストレベルのカバレッジ基準が具体的に設定されている
リスク対応	リスクの高い領域に対するテスト方針が明確である
スケジュールの実現可能性	テストスケジュールが開発計画と整合している

👁️‍🗨️ レビュー観点:

要件カバレッジ: 機能要件・非機能要件に対するテスト観点が網羅されているか
実行可能性: 体制・スキル・ツールが揃っており、計画が実行可能か
リスクベース: 業務影響度の高い機能に対して十分なテストが計画されているか
効率性: 自動化やテスト環境の共有など、効率的なテスト実施が考慮されているか

🧪成果物のサンプル

# テスト方針・計画

## テスト方針

### テスト戦略

本システムのテストは、以下の戦略に基づいて実施する。

- **早期からのテスト実施**: 設計段階からテスト観点を明確にし、早期に品質を作り込む
- **リスクベーステスト**: 業務影響度の高い機能を優先的にテストする
- **自動化の推進**: 回帰テストやデータ検証など、反復作業は自動化を検討する
- **インターフェースの重視**: モジュール間、システム間の連携部分を重点的にテストする

### テストレベル

```mermaid
graph TD
    A["単体テスト（UT）"] --> B["結合テスト（IT）"]
    
    A1["開発者"] -.担当.-> A
    B1["開発チーム"] -.担当.-> B
```

| テストレベル | 目的 | 実施者 | 実施時期 |
|------------|------|--------|---------|
| 単体テスト（UT） | 個別モジュール・関数の動作確認 | 開発者 | 実装完了後 |
| 結合テスト（IT） | モジュール間のインターフェース確認 | 開発チーム | UT完了後 |

### カバレッジ基準

- **単体テスト（UT）**
    - コードカバレッジ: C0(命令網羅) 80%以上、C1(分岐網羅) 70%以上を目標
    - 重要なビジネスロジックについてはC1 100%を目指す
- **結合テスト（IT）**
    - モジュール間のインターフェース: 100%
    - 主要な業務フロー: 100%
    - 異常系パターン: 重要度に応じて70%以上

---

## テスト種別と観点

### 単体テスト（UT）

#### テスト観点
- 正常系: 仕様通りの動作をするか
- 異常系: エラー処理が適切に実装されているか
- 境界値: 入力値の境界で正しく動作するか
- 例外処理: 想定外の入力に対して適切に処理されるか

#### テスト技法
- 同値分割法
- 境界値分析
- デシジョンテーブル
- ホワイトボックステスト（カバレッジ測定）

#### テストケース例

**関数**: validateEmail(email: string): boolean

| テストID | テスト項目 | 入力値 | 期待結果 | 優先度 |
|---------|----------|--------|---------|--------|
| UT-001 | 正常系_標準形式 | test@example.com | true | High |
| UT-002 | 正常系_サブドメイン | user@mail.example.co.jp | true | High |
| UT-003 | 異常系_@なし | testexample.com | false | High |
| UT-004 | 異常系_ドメインなし | test@ | false | High |
| UT-005 | 異常系_null | null | false | Middle |
| UT-006 | 境界値_最小長 | a@b.c | true | Middle |
| UT-007 | 境界値_最大長 | [254文字のメール] | true | Low |

### 結合テスト（IT）

#### テスト観点
- インターフェース: モジュール間のデータ受け渡しが正しいか
- データフロー: データが正しく処理・変換されるか
- トランザクション: DB操作が正しくコミット/ロールバックされるか
- エラー伝播: エラーが適切に上位モジュールに伝わるか

#### テスト技法
- トップダウンテスト
- ボトムアップテスト
- サンドイッチテスト
- ビッグバンテスト（小規模システムの場合）

#### テストケース例

**機能**: 会員登録処理（画面 → サービス → リポジトリ → DB）

| テストID | テスト項目 | テストシナリオ | 期待結果 | 優先度 |
|---------|----------|--------------|---------|--------|
| IT-001 | 正常系_新規登録 | 未登録メールで会員登録 | DBに登録、確認メール送信 | High |
| IT-002 | 異常系_重複登録 | 登録済みメールで登録試行 | エラーメッセージ、DB未更新 | High |
| IT-003 | 異常系_DB接続エラー | DB接続不可の状態で

---

🔄 設計の進め方・プロセス

🏗️ プロセス1: テスト戦略の策定

設計対象:

システム全体の品質目標を達成するための基本方針とアプローチを定義する。

具体例:

品質目標（欠陥密度、障害発生率など）をどう設定するか
リスクベーステストをどのように適用するか（業務影響度による優先順位付け）
テスト自動化をどの範囲で実施するか（単体テスト、APIテスト、E2Eテストなど）
段階的なテスト実施（シフトレフト）をどう実現するか

設計原則:

品質目標の明確化: ステークホルダーと合意した具体的な品質指標を設定し、測定可能にする
リスクベースアプローチ: 業務影響度の高い機能や技術的リスクの高い箇所を優先的にテストする
早期品質作り込み: 設計段階からテスト観点を明確にし、レビューやシフトレフトで早期に品質を確保する
効率性の追求: 繰り返し実行するテストは自動化し、手動テストは探索的テストや受入テストに集中する
継続的改善: テスト実施後の振り返りを行い、プロセスやカバレッジを継続的に改善する

文書化の推奨表現:

テスト戦略書の作成: 品質目標、リスクベースアプローチ、自動化方針を明記したテスト戦略書を作成する
リスクマトリクスの整備: 業務影響度と発生確率でリスクを評価し、優先度を可視化する
自動化スコープの明確化: どのテストレベルでどの程度自動化するか、ツールと体制を含めて記載する
戦略の根拠: なぜその戦略を選択したのか、プロジェクト特性や制約条件との関係を説明する

🏗️ プロセス2: テストレベルとカバレッジ基準の定義

設計対象:

システムの各テストレベル（単体、結合、システム、受入）の目的、範囲、カバレッジ基準を明確にする。

具体例:

単体テスト（UT）: モジュール単位のテスト、C0カバレッジ80%以上
結合テスト（IT）: モジュール間インターフェーステスト、主要フロー100%
システムテスト（ST）: エンドツーエンドの機能・性能テスト、要件カバレッジ100%
受入テスト（UAT）: ユーザー視点での業務シナリオテスト、主要業務フロー100%

設計原則:

テストレベルの責務分離: 各テストレベルで何を確認するのか、責務を明確に分離する
段階的な品質確保: 下位レベルで基礎的な品質を確保し、上位レベルで統合的な品質を確認する
カバレッジ基準の現実性: チーム体制やスケジュールを考慮し、達成可能なカバレッジ基準を設定する
非機能要件の考慮: 性能、セキュリティ、可用性など、非機能要件に対するテストも各レベルで計画する
トレーサビリティの確保: 要件とテストケースの対応関係を明確にし、要件カバレッジを測定できるようにする

文書化の推奨表現:

テストレベル定義表の作成: 各テストレベルの目的、範囲、実施者、カバレッジ基準を一覧表で整理する
カバレッジ基準の明記: C0/C1カバレッジ、要件カバレッジなど、具体的な数値目標を記載する
テスト観点の整理: 機能・非機能それぞれについて、各レベルで確認すべき観点を列挙する
責任分担の明確化: 各テストレベルの実施者、レビュー者、承認者を明記する

🏗️ プロセス3: テスト体制とスケジュールの計画

設計対象:

テスト実施に必要な体制（人員、役割、ツール）とスケジュールを具体的に計画する。

具体例:

テスト体制: テストリーダー1名、テスト実施者3名、環境担当1名
テストツール: JUnit（単体）、Selenium（E2E）、JMeter（性能）
テスト環境: 開発環境、統合テスト環境、本番相当環境
スケジュール: 単体テスト（2週間）、結合テスト（3週間）、システムテスト（4週間）

設計原則:

体制の実現可能性: チームのスキルセットや稼働可能時間を考慮し、実行可能な体制を組む
ツールの適切な選定: テスト対象の技術スタックに適合し、チームが習熟できるツールを選ぶ
環境の早期準備: テスト環境の構築リードタイムを考慮し、早期に準備を開始する
バッファの確保: 不具合修正や再テストに必要なバッファをスケジュールに組み込む
並行実施の検討: 独立したテストは並行実施し、全体のスケジュールを短縮する

文書化の推奨表現:

体制図の作成: テストチームの組織図と役割分担を視覚的に表現する
ツール一覧の整備: 使用するテストツールとバージョン、用途を一覧表にまとめる
環境構成図の作成: テスト環境の構成とネットワーク、データ準備方法を図示する
スケジュールの詳細化: ガントチャートなどでテスト工程とマイルストーンを可視化する
リスクと対策: スケジュール遅延リスクとその対策（並行実施、要員追加など）を記載する

🚨 よくある失敗と予防策　

🚧 実例収集後、追記予定

📚 参考資料・関連リンク

参考文献: 『ソフトウェアテスト技法』、『テスト駆動開発』、『アジャイルテストの実践』、JSTQB（Japan Software Testing Qualifications Board）シラバス
関連する他のガイド: システムアーキテクチャ設計、非機能要件の実現方式、外部インターフェース仕様設計
ツール・テンプレート: JUnit、Selenium、JMeter、Postman、テスト計画書テンプレート、テストケース管理ツール（TestRail、Zephyrなど）

テンプレートサイト: 📄テンプレート集