JSTQB Foundation Level を学習する中で間違えやすいポイントを備忘録として残しておく
JSTQB Foundation Level シラバス キーワード
第 1章：テストの基礎
| キーワード | 概要（シラバス記載の学習対象の例） | 参照節（ソースの該当箇所） |
|---|---|---|
| カバレッジ (Coverage) | テストの徹底度を測る指標。トレーサビリティを維持することで、カバレッジの評価を支援する。カバレッジ基準は、テスト目的がどの程度達成しているかを示す活動を遂行するための KPI として機能する。 | 1.4.4, 4.2.1, 4.3.1, 4.3.2, 5.3.1 |
| デバッグ (Debugging) | 故障の原因（欠陥）を発見し、解析し、取り除く活動。テストとは別の活動である。 | 1.1.2 |
| 欠陥 (Defect) | 人間のエラーによって生み出されるもの。故障につながることもある。静的テストや動的テストで発見の支援をする。 | 1.2.3, 5.5 |
| エラー (Error) | 人間が起こす誤り。エラー推測は、この発生を予測する技法である。 | 1.2.3, 4.4.1 |
| 故障 (Failure) | 欠陥が実行されることでシステムがすべきことをしない、またはすべきでないことをしてしまう結果。 | 1.2.3 |
| 品質 (Quality) | ソフトウェアテストは、ソフトウェアの品質を評価し、運用環境で故障が発生するリスクを低減する手助けとなる。 | 1.2.2, 5.3.1 |
| 品質保証 (Quality Assurance, QA) | プロセス指向の予防的アプローチであり、プロセスの実装と改善に焦点を当てる。 | 1.2.2 |
| 根本原因 (Root Cause) | 問題（例えばエラーにつながる状況）が発生する根底の理由。 | 1.2.3 |
| テスト分析 (Test Analysis) | テスト可能なフィーチャーを識別し、関連するテスト条件を定義し優先順位を付ける活動。 | 1.4.1 |
| テストベース (Test Basis) | テストケースを導出する元となる作業成果物など。 | 1.4.4 |
| テストケース (Test Case) | テスト条件を具現化したもの。テストケースの優先順位付けはテスト実行の順番を決める。 | 1.4.1, 4.2, 5.1.5 |
| テスト完了 (Test Completion) | プロジェクトのマイルストーンで、テストウェアの保管、教訓の識別、テスト完了レポートの作成などを行う活動。 | 1.4.1 |
| テスト条件 (Test Condition) | テストベースを分析して定義するテスト対象の要素。 | 1.4.1, 4.2 |
| テストコントロール (Test Control) | テストの目的を達成するために必要な行動（是正措置）をとる活動。 | 1.4.1, 5.3 |
| テストデータ (Test Data) | テスト実行に必要なデータ。 | 1.4.1 |
| テスト設計 (Test Design) | テスト条件をテストケースやテストチャーターなどに落とし込む活動。 | 1.4.1 |
| テスト実行 (Test Execution) | テスト実行スケジュールに従ってテストを走らせる活動。 | 1.4.1 |
| テスト実装 (Test Implementation) | テスト実行に必要なテストウェア（テストプロシジャー、自動テストスクリプト、テストデータなど）を作成または取得する活動。 | 1.4.1 |
| テストモニタリング (Test Monitoring) | すべてのテスト活動を継続的にチェックし、実際の進捗をテスト計画と比較する活動。 | 1.4.1, 5.3 |
| テスト対象 (Test Object) | テストをする対象のソフトウェアアーティファクト。 | 1.4.1, 2.2.1 |
| テスト目的 (Test Objective) | テストによって達成しようとする目的（例：欠陥の発見、品質評価、信頼の積み上げなど）。 | 1.1.1 |
| テスト計画 (Test Planning) | テスト目的を定義し、目的を最も効果的に達成するアプローチを選択する活動。テスト計画書を作成するプロセス。 | 1.4.1, 5.1 |
| テストプロシジャー (Test Procedure) | テストケースを順序立てて実行できるようにしたもの。 | 1.4.1 |
| テスト結果 (Test Result) | テストの実行により得られる結果。 | 1.4.1 |
| テスト (Testing) | 欠陥を発見し、ソフトウェアアーティファクトの品質を評価するための一連の活動。 | 1.1 |
| テストウェア (Testware) | テスト活動によって出力される作業成果物（テスト計画書、テストケース、テストデータなど）。 | 1.4.1, 1.4.3 |
| 妥当性確認 (Validation) | ユーザーやその他のステークホルダーのニーズを運用環境でシステムが満たしていることを確認する。 | 1.1 |
| 検証 (Verification) | 指定されている要件をシステムが満たすかどうかを確認する。 | 1.1 |
第 2章：ソフトウェア開発ライフサイクル全体を通してのテスト
| キーワード | 概要（シラバス記載の学習対象の例） | 参照節（ソースの該当箇所） |
|---|---|---|
| 受け入れテスト (Acceptance Testing) | 妥当性確認と、デプロイの準備ができていることの実証に焦点を当てるテストレベル。 | 2.2.1 |
| ブラックボックステスト (Black-box Testing) | 仕様に基づき、テスト対象の外観を示すドキュメントからテストを導出するテストタイプ。 | 2.2.2, 4.2 |
| コンポーネント統合テスト (Component Integration Testing) | コンポーネント間のインターフェース、および相互処理に焦点を当てるテストレベル。 | 2.2.1 |
| コンポーネントテスト (Component Testing) | コンポーネントを単独でテストすることに焦点を当てるテストレベル（ユニットテストとも呼ばれる）。 | 2.2.1 |
| 確認テスト (Confirmation Testing) | 元の欠陥が正常に修正されたことを確認するテスト。 | 2.2.3 |
| 機能テスト (Functional Testing) | コンポーネント、およびシステムが実行する機能を評価するテストタイプ。 | 2.2.2 |
| 統合テスト (Integration Testing) | コンポーネント統合テストやシステム統合テストなど、インターフェースや相互処理に焦点を当てるテスト。 | 2.2.1 |
| メンテナンステスト (Maintenance Testing) | システムへの変更や環境の更新に伴い実施されるテスト。 | 2.3 |
| 非機能テスト (Non-functional Testing) | コンポーネント、およびシステムが実行する機能特性以外の属性（性能、信頼性、使用性など）を評価するテストタイプ。 | 2.2.2 |
| リグレッションテスト (Regression Testing) | 変更によって悪影響が生じないことを確認するテスト。自動化の有力な候補となる。 | 2.2.3 |
| シフトレフト (Shift Left) | テストを SDLC の早い段階で実行するアプローチ（早期テストの原則）。 | 2.1.5 |
| システム統合テスト (System Integration Testing) | テスト対象システムと他のシステム、外部サービスとのインターフェースのテストに焦点を当てるテストレベル。 | 2.2.1 |
| システムテスト (System Testing) | システムやプロダクト全体の振る舞いや能力の全般に焦点を当てるテストレベル。 | 2.2.1 |
| テストレベル (Test Level) | 系統的にまとめ、マネジメントしていくテスト活動のグループ。 | 2.2 |
| テスト対象 (Test Object) | テストをする対象のコンポーネントまたはシステム。 | 2.2.1 |
| テストタイプ (Test Type) | 特定の品質特性に関連するテスト活動のグループ。 | 2.2 |
| ホワイトボックステスト (White-box Testing) | 構造に基づき、システムの実装または内部構造からテストを導き出すテストタイプ。 | 2.2.2, 4.3 |
第 3章：静的テスト
| キーワード | 概要（シラバス記載の学習対象の例） | 参照節（ソースの該当箇所） |
|---|---|---|
| 不正 (Anomaly) | レビュー中に識別される、作業成果物中の誤り、不備、矛盾など。 | 3.2.2, 5.5 |
| 動的テスト (Dynamic Testing) | ソフトウェアの実行を伴うテスト。静的テストと相互に補完し合う。 | 3.1.3 |
| 形式的レビュー (Formal Review) | 厳密な定義プロセスに従い、インスペクションなど監査証跡が必要な場合に使用するレビュー種別。 | 3.2.4 |
| 非形式的レビュー (Informal Review) | 定義されたプロセスに従わず、正式に文書化されたアウトプットを必要としないレビュー種別。 | 3.2.4 |
| インスペクション (Inspection) | 最も形式的なレビュー種別であり、不正を最大数発見することを主な目的とする。 | 3.2.4 |
| レビュー (Review) | 人手による確認を通じて作業成果物を評価する静的テスト技法。レビュープロセスは柔軟な枠組みを提供する。 | 3.1, 3.2.2 |
| 静的解析 (Static Analysis) | ツールを使用して作業成果物を評価する静的テスト技法。コードの特定の欠陥を検出するために使用する。 | 3.1, 3.1.2 |
| 静的テスト (Static Testing) | テスト対象のソフトウェアを実行せずに、人手やツールで評価するテスト。SDLC の初期段階で欠陥を検出できる。 | 3.1, 3.1.2 |
| テクニカルレビュー (Technical Review) | 技術的に適格なレビューアによって行われ、技術的な問題に関して合意を得て判断することを目的とするレビュー種別。 | 3.2.4 |
| ウォークスルー (Walkthrough) | 作成者が主導し、品質評価、不正の検出など多くの目的を達成できるレビュー種別。 | 3.2.4 |
第 4章：テスト分析と設計
| キーワード | 概要（シラバス記載の学習対象の例） | 参照節（ソースの該当箇所） |
|---|---|---|
| 受け入れ基準 (Acceptance Criteria) | ユーザーストーリーの実装をステークホルダーが受け入れるために満たさなければならない条件。テスト条件とみなすことができる。 | 4.5.2 |
| 受け入れテスト駆動開発 (Acceptance Test-Driven Development, ATDD) | テストファーストのアプローチで、顧客、開発担当者、テスト担当者などが共同でテストケースを作成する。 | 2.1.3, 4.5.3 |
| ブラックボックステスト技法 (Black-box Test Technique) | テスト対象の内部構造を参照することなく、仕様上の振る舞いの分析に基づく技法。 | 4.1, 4.2 |
| 境界値分析 (Boundary Value Analysis, BVA) | 同値パーティションの境界を確認することに基づいた技法。2値 BVA と 3値 BVA がある。 | 4.2.2 |
| ブランチカバレッジ (Branch Coverage) | テストケースによって通したコード内のブランチの数を計測するカバレッジ指標。 | 4.3.2 |
| チェックリストベースドテスト (Checklist-based Testing) | チェックリストのテスト条件をカバーするようにテストケースを設計、実行する経験ベースの技法。 | 4.4.3 |
| コラボレーションベースのテストアプローチ (Collaboration-based Test Approach) | コラボレーションとコミュニケーションによる欠陥の回避に焦点を当てたアプローチ。 | 4.5 |
| カバレッジ (Coverage) | テストの徹底度を測る指標。 | 4.2, 4.3 |
| カバレッジアイテム (Coverage Item) | テスト技法を適用した際に、テストによって通過させる必要がある要素。 | 4.2, 4.3 |
| デシジョンテーブルテスト (Decision Table Testing) | 条件のさまざまな組み合わせがどのようにさまざまな結果をもたらすかを仕様化している要件の実装をテストするために使用する技法。 | 4.2.3 |
| 同値分割法 (Equivalence Partitioning, EP) | データを同値パーティションに分割し、各パーティションから 1 つの値をテストするテストケースを作成する技法。 | 4.2.1 |
| エラー推測 (Error Guessing) | テスト担当者の知識に基づいて、エラー、欠陥、故障の発生を予測する経験ベースの技法。 | 4.4.1 |
| 経験ベースのテスト技法 (Experience-based Test Technique) | テストケースの設計と実装にテスト担当者の知識と経験を効果的に利用する技法。 | 4.4 |
| 探索的テスト (Exploratory Testing) | テスト担当者がテスト対象について学習しながら、テストケースを同時に設計、実行、評価する技法。 | 4.4.2 |
| 状態遷移テスト (State Transition Testing) | システムの取り得る状態と有効な遷移をモデル化し、それに基づいてテストケースを導出する技法。 | 4.2.4 |
| ステートメントカバレッジ (Statement Coverage) | テストにより通過した実行可能なステートメント数を計測するカバレッジ指標。 | 4.3.1 |
| テスト技法 (Test Technique) | 比較的少ないながらも十分なテストケースのセットを体系的に開発するのに役立つ手法。 | 4.1 |
| ホワイトボックステスト技法 (White-box Test Technique) | テスト対象の内部構造や処理の分析に基づく技法。 | 4.1, 4.3 |
第 5章：テスト活動のマネジメント
| キーワード | 概要（シラバス記載の学習対象の例） | 参照節（ソースの該当箇所） |
|---|---|---|
| 欠陥マネジメント (Defect Management) | 報告された不正を発見から終結まで処理するためのワークフローを含むプロセス。 | 5.5 |
| 欠陥レポート (Defect Report) | 報告された欠陥の処理・解決のための情報を提供する、または作業成果物の品質を追跡する目的で作成する文書。 | 5.5 |
| 開始基準 (Entry Criteria) | ある活動を行うための事前条件を定義するもの。アジャイルでは「準備完了（Ready）の定義」とも呼ぶ。 | 5.1.3 |
| 終了基準 (Exit Criteria) | 活動の完了を宣言するために何を達成しなければならないかを定義するもの。アジャイルでは「完了（done）の定義」とも呼ぶ。 | 5.1.3 |
| プロダクトリスク (Product Risk) | プロダクトの品質特性に関連するリスク。テストの深さと範囲に影響を与える。 | 5.2.2, 5.2.3 |
| プロジェクトリスク (Project Risk) | プロジェクトのマネジメントや統制に関連するリスク（例：納期遅れ、スキル不足）。 | 5.2.2 |
| リスク (Risk) | 顕在化することによって悪影響が生じる、潜在的な事象。 | 5.2.1 |
| リスク分析 (Risk Analysis) | リスク識別とリスクアセスメント（可能性と影響の決定）から構成される活動。 | 5.2.3 |
| リスクアセスメント (Risk Assessment) | 識別したリスクを分類し、リスクの可能性、リスクの影響、レベルを決定し、優先順位を付ける活動。 | 5.2.3 |
| リスクコントロール (Risk Control) | リスク軽減とリスクモニタリングから構成される、識別し評価したリスクに対応する手段。 | 5.2.4 |
| リスク識別 (Risk Identification) | リスクの包括的なリストを作成する活動。 | 5.2.3 |
| リスクレベル (Risk Level) | リスクの可能性とリスクの影響（損害）の二つの要素で表されるリスクの尺度。 | 5.2.1 |
| リスクマネジメント (Risk Management) | 組織が目的を達成する可能性を高め、プロダクトの品質を向上させることを可能にする活動。 | 5.2 |
| リスク軽減 (Risk Mitigation) | リスクアセスメントで提案された措置を実施し、リスクレベルを低減させること。 | 5.2.4 |
| リスクモニタリング (Risk Monitoring) | リスク軽減措置が効果的であることを確認し、新たなリスクを識別する活動。 | 5.2.4 |
| リスクベースドテスト (Risk-based Testing) | リスク分析とリスクコントロールに基づいてテスト活動を選択し、優先順位を付け、マネジメントしていくテストアプローチ。 | 5.2 |
| テストアプローチ (Test Approach) | テスト計画書の構成要素（テスト戦略やテストレベル、テストタイプ、テスト技法、テスト成果物など）。 | 5.1.1 |
| テスト完了レポート (Test Completion Report) | テストの特定の段階の完了時に作成し、テスト活動を要約するレポート。 | 5.3.2 |
| テストコントロール (Test Control) | テストモニタリングからの情報を用いて、必要な補正のアクションを提供する活動。 | 5.3 |
| テストモニタリング (Test Monitoring) | テストに関する情報を収集し、進捗を評価する活動。 | 5.3 |
| テスト計画書 (Test Plan) | テストプロジェクトの目的、リソース、プロセスを表す文書。 | 5.1.1 |
| テスト計画 (Test Planning) | テスト計画書を作成するプロセス。 | 5.1 |
| テスト進捗レポート (Test Progress Report) | テストの継続的なコントロールを支援するために定期的に作成するレポート。 | 5.3.2 |
| テストピラミッド (Test Pyramid) | 異なるテストレベルにおける粒度とテスト自動化の度合いを示すモデル。 | 5.1.6 |
| テストの四象限 (Test Quadrants) | テストレベルを、アジャイルソフトウェア開発における適切なテストタイプ、活動、技法、作業成果物に分類するモデル。 | 5.1.7 |
| 構成管理 (Configuration Management, CM) | テストウェアなどの作業成果物を識別、コントロール、トラッキングするための規律。 | 5.4 |
第 6章：テストツール
| キーワード | 概要（シラバス記載の学習対象の例） | 参照節（ソースの該当箇所） |
|---|---|---|
| テスト自動化 (Test Automation) | テストツールを使用し、反復作業の削減や一貫性の向上などの利点をもたらす活動。ツールの導入、保守、トレーニングが必要となる。 | 6.2, 6.2.1 |