JSTQBにおけるテストドキュメンテーションの要約
✅ テストドキュメンテーションとは？
テスト活動を 計画・設計・実行・評価・報告 するために作成される ドキュメント群 のことです。これにより、以下が可能になります：
- テストの品質保証
- 関係者間の共通認識形成
📄 主なテストドキュメントの種類（ISTQBシラバス準拠）
| ドキュメント名 | 内容の概要 |
|---|---|
| テスト計画書（Test Plan） | テストの目的、範囲、リソース、スケジュールなどを定める。プロジェクトマネジメント視点で重要。 |
| テスト設計仕様書（Test Design Specification） | テスト条件、テスト項目、テストパスなどを記述。どのようなテストを行うかを設計レベルで記述。 |
| テストケース仕様書（Test Case Specification） | 各テストケースの入力、期待結果、実行条件などを定義。 |
| テスト手順仕様書（Test Procedure Specification） | テストケースの実行手順や順序を記述。 |
| テストスイート（Test Suite） | 関連するテストケースをまとめたもの。 |
| テスト実行ログ（Test Log） | 実際のテスト実行中に記録するログ。 |
| テストサマリ報告書（Test Summary Report） | テスト結果の要約、達成度、問題点、評価、結論などを報告。 |
| 欠陥報告書（Defect Report） | 発見された不具合の詳細情報を記載。 |
📌 テストドキュメントの目的
- テスト活動の 透明性 を高める
- 再現性と一貫性 の確保
- トレーサビリティ（要件との対応関係）の維持
- 監査やレビュー の材料となる
- チーム間やステークホルダーとの 情報共有
🧠 ポイントまとめ
- ドキュメントは 目的と状況に応じて簡略化・柔軟化 してよい（例：アジャイル開発）。
- IEEE 829規格 など、国際的な標準フォーマットが存在する。
- ドキュメントの質は テストの成功に大きく影響 する。
IEEE 829規格に基づくテストドキュメントフォーマット一覧
IEEE 829（正式名称：Standard for Software Test Documentation）は、ソフトウェアテストに関するドキュメントの構造や内容を標準化した国際的な規格です。
以下に、IEEE 829で定義されている代表的なテストドキュメントとその主な構成要素をまとめます。
✅ 1. テスト計画書（Test Plan）
目的： テスト活動全体の方針、範囲、スケジュール、役割などを明確にする
構成項目（一部抜粋）:
- テスト計画の識別子
- 導入（背景・目的など）
- テスト対象
- テスト項目
- 除外項目
- テストアプローチ
- 合格・不合格基準
- テスト実行の停止・再開条件
- テスト成果物
- スケジュール
- 要員と責任
- リスクと対応策
✅ 2. テスト設計仕様書（Test Design Specification）
目的： テスト条件、テストの選定基準、網羅する機能を定義
構成項目:
- テスト設計仕様の識別子
- 対象となるテスト項目
- 入出力仕様
- テスト条件
- テストの通過基準
- 必要な特別な環境やツール
✅ 3. テストケース仕様書（Test Case Specification）
目的： 各テストケースの詳細（入力、手順、期待結果など）を明記
構成項目:
- テストケース識別子
- 関連テスト設計仕様
- 前提条件
- 入力データ
- 実行手順
- 期待結果
- 後処理条件
✅ 4. テスト手順仕様書（Test Procedure Specification）
目的： テストの実行順序や方法を記述
構成項目:
- テスト手順識別子
- 実行の前提条件
- 実行手順（ステップごとの詳細手順）
- 確認方法
✅ 5. テスト項目一覧（Test Item Transmittal Report）
目的： テスト対象となるソフトウェアやモジュールのバージョン、構成の情報を記録
構成項目:
- テスト項目の識別子
- バージョン情報
- 関連ドキュメント
- 状態（レビュー済、リリース済など）
✅ 6. テスト実行ログ（Test Log）
目的： テスト実行中の詳細な記録を取る（何を、いつ、どう実行したか）
構成項目:
- ログ識別子
- 実行日時
- 実行者
- 実行したテストケース
- 結果（成功/失敗）
- コメント
✅ 7. テストサマリ報告書（Test Summary Report）
目的： テスト活動全体の総括と評価を報告
構成項目:
- 報告書識別子
- テストの目的と範囲
- 実施したテストの概要
- 成果物の一覧
- 欠陥の概要
- テスト結果の評価
- 結論と推奨事項
✅ 8. 欠陥報告書（Incident Report / Defect Report）
目的： テスト中に発見された不具合や異常の詳細を報告
構成項目:
- 欠陥識別子
- 検出日時と検出者
- 関連するテストケース
- 問題の詳細な説明
- 再現手順
- スクリーンショットやログなどの添付情報
- 影響範囲
- 状態（未対応、対応中、修正済など）
📝 備考
- IEEE 829は現在ではISO/IEC/IEEE 29119シリーズに置き換わりつつある。
- ただし、JSTQB Foundationレベルなどでは現在もIEEE 829のドキュメント体系をベースにしている。。
参考：
- JSTQB Foundation Level シラバス
- IEEE 829: Standard for Software and System Test Documentation
IEEE 29119に基づくテストドキュメント構成（Markdown形式）
IEEE 29119は、IEEE 829の後継として制定された国際標準規格で、より柔軟かつリスクベースに対応できるように設計されています。
特に Part 3（Test Documentation） では、テスト関連ドキュメントの標準構成が定義されています。
🧩 IEEE 29119の構成概要
| パート名 | 内容 |
|---|---|
| Part 1: Concepts and Definitions | テストの基本概念と用語の定義 |
| Part 2: Test Processes | テストプロセスの標準（組織・プロジェクト・動的テスト） |
| Part 3: Test Documentation | テストドキュメントの構成 |
| Part 4: Test Techniques | ブラックボックス、ホワイトボックスなどのテスト技法 |
| Part 5: Keyword-Driven Testing | キーワード駆動テストの導入と手順 |
📄 IEEE 29119 Part 3：テストドキュメント一覧
IEEE 29119では、プロジェクトの規模・ドメイン・リスクに応じて必要なドキュメントを選択できます。以下に代表的なドキュメントとその構成をまとめます。
✅ 1. テストポリシー（Test Policy）
目的： 組織全体のテストに関する方針を定義
主な構成：
- 方針の目的と範囲
- 組織のテスト目標
- 標準・規約の使用方針
✅ 2. テスト戦略（Test Strategy）
目的： 組織または複数プロジェクトにまたがる共通のテスト戦略を明示
主な構成：
- リスクベースのアプローチ
- テストレベルごとの方針
- 使用する技法・ツール
- テストプロセスの定義
✅ 3. テスト計画書（Test Plan）
目的： 各プロジェクトまたはフェーズ単位の詳細なテスト計画を策定
主な構成：
- テストの目的とスコープ
- スケジュール
- リソース計画
- テスト項目
- 環境／ツール
- リスクと緩和策
- 測定基準と合格基準
✅ 4. テスト設計仕様書（Test Design Specification）
目的： テストの設計方針と対象の詳細を定義
主な構成：
- テスト条件の識別
- 入出力の定義
- カバレッジ基準
- テスト完了条件
✅ 5. テストケース仕様書（Test Case Specification）
目的： 各テストケースの詳細（前提、手順、入力、期待結果など）を定義
主な構成：
- テストケースID
- 入力データ
- 実行手順
- 期待結果
- 前提・後処理
✅ 6. テスト手順仕様書（Test Procedure Specification）
目的： テストをどの順序・手順で実行するかを定義
主な構成：
- 実行順序
- 実行条件
- 自動化の有無
✅ 7. テスト実行ログ（Test Execution Log）
目的： 実施されたテストとその結果を時系列で記録
主な構成：
- 実行日
- 実行者
- 実行環境
- 結果と備考
✅ 8. テストサマリ報告書（Test Summary Report）
目的： テスト活動全体の要約と品質評価を提供
主な構成：
- テストの範囲
- 達成状況
- 欠陥の要約
- リスクと対応
- 結論と推奨事項
✅ 9. 欠陥報告書（Incident Report）
目的： テスト中に発見された問題や不具合の報告
主な構成：
- インシデントID
- 発見環境
- 発生手順
- 影響範囲
- 再現可否
- ステータス
📌 IEEE 829との違い（簡易比較）
| 比較項目 | IEEE 829 | IEEE 29119 |
|---|---|---|
| 柔軟性 | 固定構成 | 選択式・リスクベース |
| 標準化レベル | 高 | 高だが柔軟に調整可能 |
| 現代開発への適応 | やや古い | アジャイル・DevOpsも考慮 |
| 推奨対象 | 組織全体で共通 | 組織・プロジェクト・ドメインごとにカスタマイズ可能 |
📝 補足
- IEEE 29119は、厳密に全ドキュメントを揃える必要はなく、プロジェクトの性質やリスクに応じて選択・統合して使用する。
- アジャイル開発では「軽量化」した形で取り入れることも可能。
参考：
- ISO/IEC/IEEE 29119-3: Software and systems engineering — Software testing — Part 3: Test documentation
- JSTQB Advanced Level シラバス
🧪 テスト計画書（Test Plan）【IEEE 29119 準拠テンプレート】
1. テスト計画の識別情報
- ドキュメントID： TP-YYYYMMDD-XXX
- 作成日： YYYY-MM-DD
- 作成者： [氏名]
- バージョン： v1.0
- 関連ドキュメント： 要件仕様書、設計書、テスト戦略 など
2. テストの目的と背景
この文書は、[プロジェクト名やシステム名] に対するテスト活動の計画を示すものである。目的は以下の通り：
- システムが要件を満たしているか検証する
- リスクを低減し、品質を保証する
3. テスト対象（Test Items）
以下の項目が本テストの対象です：
- 機能A（例：ログイン機能）
- 機能B（例：商品検索）
- 画面・API・バッチなど
4. テストのスコープ
✅ 含まれる内容（In Scope）
- 単体テスト、結合テスト、システムテスト
- [対象ブラウザ・OSなど]
❌ 含まれない内容（Out of Scope）
- 本番環境でのテスト
- 他システムとの連携検証（別チーム対応）
5. テストアプローチ（Test Approach）
- テストレベル： 結合テスト、システムテスト
- テストタイプ： 機能テスト、非機能テスト（パフォーマンス、セキュリティ）
- テスト技法： 等価クラステスト、境界値分析、状態遷移テスト
- リスクベース： 高リスク機能から優先的にテスト
6. 合格・不合格基準（Pass/Fail Criteria）
- テストケース成功率が95%以上
- 重大な不具合（Severity 1, 2）が残っていない
7. テスト成果物（Deliverables）
- テスト設計仕様書
- テストケース仕様書
- テスト実行ログ
- テストサマリ報告書
- 欠陥報告書
8. テストスケジュール
| テストフェーズ | 開始日 | 終了日 |
|---|---|---|
| テスト設計 | YYYY-MM-DD | YYYY-MM-DD |
| テスト実装 | YYYY-MM-DD | YYYY-MM-DD |
| テスト実行 | YYYY-MM-DD | YYYY-MM-DD |
| テスト報告 | YYYY-MM-DD | YYYY-MM-DD |
9. テスト環境
- OS: Windows 11 / Ubuntu 22.04
- ブラウザ: Chrome, Edge
- テストツール: Selenium, JUnit, JMeter
- データベース: PostgreSQL 15
- APIモックツール: WireMock など
10. リソースと責任分担
| 役割 | 担当者 | 備考 |
|---|---|---|
| テストマネージャ | 氏名A | 全体管理 |
| テスト設計者 | 氏名B | テストケース作成 |
| テスト実行者 | 氏名C | 手動・自動テスト |
11. リスクと対策（Risk and Contingency Plan）
| リスク内容 | 影響度 | 対応策 |
|---|---|---|
| テスト環境の構築遅延 | 高 | 事前に環境確認・予備環境用意 |
| テスト要員の不足 | 中 | 他チームから応援を依頼 |
| 仕様変更の頻発 | 高 | イテレーティブに見直し |
12. 測定基準（Metrics）
- テストケース成功率（Pass Rate）
- 欠陥密度（Defect Density）
- 欠陥検出率（Defect Detection Rate）
- テストカバレッジ（Coverage by requirements）
13. レビューと承認
| 役割 | 氏名 | 承認日 |
|---|---|---|
| 作成者 | ||
| レビュー者 | ||
| 承認者 |
※このテンプレートは、IEEE 29119-3（Test Documentation）に準拠しつつ、日本国内の慣例に合わせて実務的にカスタマイズされたもの。