全74問から、出題範囲の骨格が掴める28問だけを抜き出しました。まずはここだけ流して、必要なら全問へ進んでください。
全74問に進むこの28問の内容
出典: オリジナル想定問題（当サイト作成、実際の過去問ではありません）。公表されている出題範囲に基づく（最終更新 2026-10-15）
あるプロジェクトでは、計画されたテストケースをすべて実行し欠陥が1件も検出されなかったため、プロダクトマネージャーは「このソフトウェアには欠陥が存在しない」と結論づけた。この判断の誤りを説明するテストの原則はどれか。
- A殺虫剤のパラドックス
- B欠陥の偏在
- ✓テストは欠陥がないことを示せない
- D早期テストで時間とコストを節約できる
解説
テストで欠陥が検出されないことは、欠陥が存在しないことの証明にはならないというのがテストの原則の一つである。欠陥がないことを示せないにもかかわらず、存在しないと断定した点が誤り。
根拠JSTQB Foundation Levelシラバス 第1章 テストの基礎 - テストの7原則（テストは欠陥がないことを示せない）
機能を実装した開発者自身が、その機能の単体テストだけでなく受け入れテストの設計も担当した。この体制で生じやすい問題として最も適切なものはどれか。
- Aテストオラクル問題が発生する
- B殺虫剤のパラドックスが発生する
- Cテスト条件の重複が必然的に発生する
- ✓自分が作成した設計の誤りに対して盲点が生じやすい
解説
テスト担当者の独立性が低いほど、作成者自身の思い込みや前提に基づく欠陥（確認バイアス）を見逃しやすくなる。独立したテスト担当者が関与することで、こうした盲点を減らせる。
根拠JSTQB Foundation Levelシラバス 第1章 テストの基礎 - テストの心理学（独立性）
検証(verification)と妥当性確認(validation)の違いに関する記述として正しいものはどれか。
- A検証は「正しいプロダクトを構築しているか」を確認し、妥当性確認は「プロダクトを正しく構築しているか」を確認する
- ✓検証は仕様などの要求どおりに構築されているかを確認し、妥当性確認はユーザーの意図したニーズを満たしているかを確認する
- C検証と妥当性確認はどちらもユーザーの利用シーンのみを対象とする
- D検証は動的テストのみで行われ、妥当性確認は静的テストのみで行われる
解説
検証は仕様や要件どおりにプロダクトが構築されているかを確認する活動であり、妥当性確認はそのプロダクトが実際のユーザーのニーズや意図した用途を満たしているかを確認する活動である。両者は目的が異なる。
根拠JSTQB Foundation Levelシラバス 第1章 テストの基礎 - 検証と妥当性確認の違い
JSTQB Foundation Levelのテストプロセスにおいて、一般的に行われる活動の順序として適切なものはどれか。
- Aテスト実行 → テスト分析 → テスト設計 → テスト完了
- Bテスト設計 → テスト分析 → テスト実行 → テスト実装
- ✓テスト分析 → テスト設計 → テスト実装 → テスト実行
- Dテスト実装 → テスト分析 → テスト設計 → テスト実行
解説
テストプロセスでは、テストベースを分析してテスト条件を導くテスト分析の後、テストケースを作成するテスト設計、テストスクリプトなどを整備するテスト実装、そして実際にテストを行うテスト実行という順序で進む。
根拠JSTQB Foundation Levelシラバス 第1章 テストの基礎 - テストプロセスの活動
品質保証(QA)とテスト（品質コントロールの一部）の関係に関する記述として正しいものはどれか。
- Aテストは品質保証そのものであり、品質コントロールとは無関係である
- ✓品質保証はプロセスに焦点を当て、テストはプロダクトの欠陥検出に焦点を当てた品質コントロール活動の一部である
- C品質保証はテスト実行後に行う最終承認のみを指す
- D品質保証とテストは同義語であり、プロセスとプロダクトという観点の違いはない
解説
品質保証はプロセスが適切であることを確保する活動であり、テストはプロダクトの欠陥を検出し品質を評価する品質コントロール活動の一部である。両者は焦点（プロセスかプロダクトか）が異なる。
根拠JSTQB Foundation Levelシラバス 第1章 テストの基礎 - 品質保証とテストの関係
ある金融システムのテストにおいて、過去6か月間に報告された欠陥の約80%が、全体のわずか20%に相当する特定の口座振替モジュールに集中していることが判明した。次期リリースのテスト計画にこの情報を活かす対応として最も適切なものはどれか。
- ✓欠陥の偏在が確認されたモジュールに対して、テストの労力を重点的に配分する
- B欠陥が集中したモジュールは既に十分検証されたとみなし、テストの重点を他のモジュールに移す
- C欠陥集中は偶然の結果に過ぎないため、今後のテスト計画には反映しない
- D欠陥が多いモジュールは品質保証担当者ではなく開発担当者のみが修正すべきであり、テスト対象から除外する
解説
欠陥の偏在（欠陥クラスタリング）の原則では、欠陥は少数のモジュールに集中する傾向があるとされ、過去に多くの欠陥が見つかった箇所には将来も欠陥が潜んでいる可能性が高いため、重点的にテストを行うべきである。
根拠JSTQB Foundation Levelシラバス - テストの原則（欠陥の偏在）
あるテスト対象は3つの入力項目を持ち、それぞれ10通りの値を取り得るため理論上1000通りの組み合わせが存在する。テスト担当者はこのうちリスクが高いと判断した20通りのみを選んでテストすることにした。この判断の根拠となるテストの原則はどれか。
- Aバグゼロの落とし穴
- Bテストは状況次第
- ✓全数テストは不可能
- D欠陥の偏在
解説
全数テスト（すべての組み合わせの網羅）は現実的に不可能であるため、リスク分析に基づいて優先順位をつけ、限られたテストケースで効果的にテストを行う必要がある、というのが全数テスト不可能の原則である。
根拠JSTQB Foundation Levelシラバス - テストの原則（全数テストは不可能）
ある口座振込アプリケーションにおいて、振込金額の入力欄に対する境界値（0円、1円、上限金額、上限+1円など）を検証するテストと、口座の状態（通常、凍結、休止）が操作によってどのように遷移するかを検証するテストは、それぞれどのテスト技法の分類に該当するか。
- A前者も後者もランダムテストに分類される
- B前者は状態遷移テスト、後者はドメインテストに分類され、両者ともルールに基づくテスト技法である
- ✓前者はドメインテスト（データに基づくテスト技法）、後者は状態遷移テスト（振る舞いに基づくテスト技法）に分類される
- D前者も後者とも振る舞いに基づくテスト技法に分類される
解説
入力値の境界に注目する技法はデータに基づくテスト技法に分類されるドメインテストであり、システムの状態変化を検証する技法は振る舞いに基づくテスト技法に分類される状態遷移テストである。両者は着目する観点が異なるため分類も異なる。
根拠JSTQB Advanced Level シラバス テストアナリスト(CTAL-TA) 3.1.1 ドメインテスト、3.2.2 状態遷移テスト
ある顧客管理システムにおいて、顧客情報の登録・参照・更新・削除の各操作が正しく実行され、データの整合性が保たれているかを確認したい。この目的に最も適したテスト技法はどれか。
- A状態遷移テスト
- Bメタモルフィックテスト
- Cランダムテスト
- ✓CRUDテスト
解説
データの作成・参照・更新・削除（Create/Read/Update/Delete）操作の整合性を確認する技法はCRUDテストであり、振る舞いに基づくテスト技法の一つに分類される。
根拠JSTQB Advanced Level シラバス テストアナリスト(CTAL-TA) 3.2.1 CRUDテスト
「入力に特定の変換（メタモルフィック関係）を適用した際に、出力が満たすべき関係を検証することで、個々の期待結果が未知であってもテスト対象の正しさを検証できるテスト技法」として最も適切なものはどれか。
- Aデシジョンテーブルテスト
- Bシナリオベースドテスト
- ✓メタモルフィックテスト
- Dセッションベースドテスト
解説
メタモルフィックテストは、テストオラクル問題（個々の期待結果を直接決定できない場合）に対する解決策の一つであり、入力の変換前後で出力が満たすべき関係（メタモルフィック関係）を検証する技法である。
根拠JSTQB Advanced Level シラバス テストアナリスト(CTAL-TA) 3.3.2 メタモルフィックテスト、1.3.1.3.4 テストオラクルの決定
状態遷移テストを用いてテストケースを設計する際の一般的な進め方として適切な順序はどれか。
- Aテストケースの実行 → 状態遷移図の作成 → カバレッジ基準の決定 → 状態遷移テーブルの作成
- Bカバレッジ基準の決定 → テストケースの導出 → 状態遷移図の作成 → 遷移経路の識別
- C状態遷移テーブルの作成 → テストケースの実行 → 状態遷移図の作成 → カバレッジ基準の決定
- ✓状態遷移図（または状態遷移テーブル）の作成 → カバレッジ基準の決定 → カバレッジ基準を満たす遷移経路の識別 → テストケースの導出
解説
状態遷移テストでは、まずシステムの振る舞いを状態遷移図やテーブルでモデル化し、カバレッジ基準を決定した上でそれを満たす遷移経路を識別し、最後にテストケースを導出するという順序で進めるのが一般的である。
根拠JSTQB Advanced Level シラバス テストアナリスト(CTAL-TA) 3.2.2 状態遷移テスト
あるWebフォームには「配送方法」（3種類）、「支払方法」（4種類）、「会員ランク」（2種類）の3つの入力パラメータがある。これらの組み合わせを全数テストする場合、必要なテストケースの最大数はいくつか。
- A9
- B12
- ✓24
- D48
解説
全数組み合わせテストでは各パラメータの値の数を単純に掛け合わせるため、3×4×2=24通りのテストケースが必要になる。
根拠JSTQB Advanced Level シラバス テストアナリスト(CTAL-TA) 3.1.2 組み合わせテスト
ハイレベルテストケース（抽象テストケース）とローレベルテストケース（具体的テストケース）の違いに関する記述として正しいものはどれか。
- Aハイレベルテストケースには具体的な入力データや期待結果が含まれるが、ローレベルテストケースには含まれない。
- Bローレベルテストケースは通常、ハイレベルテストケースより先に設計され、その後抽象化される。
- ✓ハイレベルテストケースは、どのテスト条件をカバーするかを抽象的に記述し、具体的な入力データや期待結果を含まない。
- Dハイレベルテストケースとローレベルテストケースは同じ抽象度を持ち、呼び方が異なるだけである。
解説
ハイレベルテストケースはテスト条件のカバレッジを抽象的に示すものであり、具体的な入力データや期待結果はローレベルテストケースで詳細化される。通常はハイレベルを先に設計し、それを基にローレベルを導出する。
根拠CTAL-TAシラバス 1.3.1 ハイレベルテストケースとローレベルテストケース
テストオラクル問題の解決策の一つである「疑似オラクル」の説明として最も適切なものはどれか。
- Aテスト対象への入力に特定の変換を適用し、出力が満たすべき関係を検証する手法
- Bテスト対象の定義されたプロパティを用いて入力と期待結果の関係を検証する手法
- C人間の経験や知識を用いて期待結果を判断する手法
- ✓テスト対象と同じ仕様を満たす、独自に開発された別のシステム（レガシーシステムや簡易版など）を用いて期待結果を得る手法
解説
疑似オラクルは、テスト対象と同じ仕様を満たす独自開発の別システムを用いて期待結果を得る解決策であり、選択肢1はメタモルフィックテスト、選択肢2はプロパティベースのテスト、選択肢3は人間オラクルの説明である。
根拠CTAL-TAシラバス 1.3.4 テストオラクルの決定（疑似オラクル）
あるプロジェクトのプロダクトリスク分析で、テストアナリストが果たす一般的な役割の説明として最も適切なものはどれか。
- Aプロダクトリスクの識別はテストレベルの技術的な事項であるため、プロジェクトマネージャーのみが行う
- Bプロダクトリスク分析はテスト計画のみに関係し、テスト設計には一切影響を与えない
- Cテストマネージャーに代わってリスクベースドテストの全体方針とリスクレベルの合否判定基準を最終決定する
- ✓自身の専門知識やテストベースの分析に基づき、プロダクトリスクの識別と評価（発生確率・影響度の見積り）に貢献する
解説
リスクベースドテストの方針自体はテストマネージャーが定めるが、テストアナリストはプロダクトリスク分析（リスクの識別・評価）に実務的な専門知識をもって積極的に貢献する役割を担う。
根拠Advanced Level シラバス テストアナリスト(CTAL-TA) 第2章 リスクベースドテストにおけるテストアナリストのタスク、2.1 リスク分析
個人情報を含む本番相当のテストデータを用意する際、個人を特定できる情報を削除し、元の個人情報へ復元できない形に加工したデータを作成した。このデータの加工方法を表す用語として適切なものはどれか。
- ✓匿名化データ
- B仮名化データ
- C合成データ
- D疑似データ
解説
仮名化データは個人情報を人工的な識別子に置き換える（可逆的な場合がある）処理であるのに対し、匿名化データは個人を識別できる情報を削除し復元できないようにする処理である。
根拠Advanced Level シラバス テストアナリスト(CTAL-TA) 1.3.5 テストデータ要件（機密性）
テスト実装においてテストプロシジャーを定義する際、一般的に含めるべき要素を実行順に並べたものとして適切なのはどれか。
- A期待結果の検証→事前条件の設定→実行後のリセット手順→テストケースのステップ実行
- ✓事前条件の設定→テストケースのステップ実行→期待結果・事後条件の検証→実行後のリセット手順
- C実行後のリセット手順→テストケースのステップ実行→事前条件の設定→期待結果の検証
- Dテストケースのステップ実行→実行後のリセット手順→事前条件の設定→期待結果の検証
解説
テストプロシジャーには、初期の事前条件の設定、一連のテストケースのステップ、期待結果および事後条件の検証、実行後のリセット手順の順で含める必要がある。
根拠Advanced Level シラバス テストアナリスト(CTAL-TA) 1.2.3 テスト実装
テストウェアのマネジメントに用いるツールのうち、テストマネジメントツールと欠陥マネジメントツールの違いに関する記述として正しいものはどれか。
- A欠陥マネジメントツールはテスト環境の構成管理を主な目的とし、テストマネジメントツールは機密データの保護を主な目的とする
- Bテストマネジメントツールと欠陥マネジメントツールは同一の機能を提供するため、プロジェクトでは必ずどちらか一方のみを導入すればよい
- C欠陥マネジメントツールはテストケースの設計を自動生成する機能を主目的とし、テストマネジメントツールは欠陥の根本原因分析を主目的とする
- ✓テストマネジメントツールはテスト条件・テストケース・テストランなどのリポジトリとトレーサビリティやテスト進捗のレポートを提供するのに対し、欠陥マネジメントツールは欠陥解決プロセスの記録・優先順位付け・モニタリングに特化している
解説
テストマネジメントツールは関連テストウェアのリポジトリ、トレーサビリティ、進捗レポートなどを提供し、欠陥マネジメントツールは欠陥解決プロセスの記録・優先順位付け・モニタリングに特化しているという役割の違いがある。
根拠Advanced Level シラバス テストアナリスト(CTAL-TA) 1.3.7 テストウェアのマネジメントに適用するツール
JSTQBの行動規範における『マネジメント』の原則として適切なものはどれか。
- A認定されたソフトウェアテスト担当者は、常に公人として行動しなければならない
- B認定されたソフトウェアテスト担当者による成果物は、プロフェッショナルとして高いレベルのものでなければならない
- C認定されたソフトウェアテスト担当者は、生涯その専門性を磨くための学習を続けなければならない
- ✓認定されたソフトウェアテストマネジメントおよびリーダは、ソフトウェアテストのマネジメントに対する倫理的なアプローチに同意した上で、これを推進しなければならない
解説
行動規範の『マネジメント』の原則は、テストのマネジメントおよびリーダに対し、倫理的なアプローチへの同意とその推進を求めるものであり、他の選択肢はそれぞれ『公人』『プロダクト』『自身』の原則に該当する。
根拠JSTQBシラバス・用語集ページ 行動規範（マネジメント）
ソフトウェア開発ライフサイクル(SDLC)モデルごとのテストアナリスト(TA)の関与の違いに関する記述として正しいものはどれか。
- Aインクリメンタルモデルでは全インクリメントの開発が完了してから一括してテスト分析を行う
- Bイテレーティブモデルでは、一度定義したテスト条件やテストケースを変更せず固定して使い続ける
- ✓シーケンシャルモデルでは、TAのタスクは時間の経過とともに変化し、SDLC初期はテスト計画の支援に重点を置き、後期にテスト実行を行う
- Dインクリメンタルモデルでは、新規フィーチャーのみに焦点を当て、リグレッションのリスクへの配慮は不要である
解説
シーケンシャル開発モデルでは開発フェーズに重複がなく、TAの活動も計画支援からテスト実行へと時間の経過とともに変化する。インクリメンタルモデルでは各インクリメントで同じ活動を繰り返し、リグレッションリスクへの注意が重要になる。
根拠ISTQB Advanced Level テストアナリスト(CTAL-TA) v4.0.J01 1.1.1項 さまざまなソフトウェア開発ライフサイクルにおけるテストアナリストの関与
テスト実行に必要なデータが外部システムの未実装や利用不能によって欠落している場合、その欠落に対処するための手法の説明として最も適切なものはどれか。
- A本番環境のデータをそのまま仮想環境にコピーして利用する手法
- Bテスト対象システム自体を仮想マシン上で実行する手法
- C複数のテスト環境を仮想的に統合して一つの環境として扱う手法
- ✓存在しないサービスやアクセスできないサービスをシミュレーターで再現し、外部システムやサービスとの相互作用を可能にする手法
解説
サービス仮想化は、存在しないサービスやアクセスできないサービスをシミュレーターで再現することで、データや依存先の欠落に対処する手法である。
根拠ISTQB Advanced Level テストアナリスト(CTAL-TA) v4.0.J01 1.3.5項 テストデータ要件（可用性）
テストウェアのマネジメントに適用するツールのうち、テストデータマネジメントツールと構成管理ツールの違いに関する記述として正しいものはどれか。
- Aテストデータマネジメントツールは欠陥解決のプロセスを記録・優先順位付け・モニタリングするものであり、構成管理ツールはテストケースのリポジトリを提供するものである。
- ✓テストデータマネジメントツールは機密データの保護を含めテストデータを作成・保守するものであり、構成管理ツールはテスト環境の構成や可用性のマネジメントなど、開発・リリース・運用プロセスにおけるテスト関連の活動を促進するものである。
- Cテストデータマネジメントツールはハイレベルの要件を格納・追跡するものであり、構成管理ツールはテストデータを生成するものである。
- D両ツールはいずれも要件のバージョン管理を主目的とする点で共通する。
解説
シラバスでは、テストデータマネジメントツールは機密データの保護を含めテストデータを作成・保守するものと説明され、構成管理ツールはテスト環境の構成や可用性のマネジメントなど開発・リリース・運用プロセスにおけるテスト関連活動を促進するものと説明されている。選択肢1は欠陥マネジメントツールとテストマネジメントツールの説明の混同である。
根拠JSTQB Advanced Level テストアナリスト(CTAL-TA)シラバス Version4.0.J01 1.3.7節 テストウェアのマネジメントに適用するツール
あるテストアナリストがテスト分析を開始しようとしたところ、テスト計画がまだ策定されておらずテスト範囲やテストアプローチも明確になっていなかった。このときテストアナリストが確認すべき開始基準として適切なものはどれか。
- Aすべてのテストケースが既にレビューされ承認されていること。
- Bテスト環境が完全にセットアップされ、テスト実行の準備が整っていること。
- ✓テスト計画が行われており、テスト範囲、テスト目的、テストアプローチが明確になっていること。
- D自動テストスクリプトがすべて実装済みであること。
解説
シラバスでは、テスト分析を効果的に進めるための開始基準として、テスト計画が行われ、テスト範囲・テスト目的・テストアプローチが明確になっていることを確認するよう記述されている。選択肢1・4はテスト設計・実装段階の話であり、選択肢2はテスト実装中に検証すべき事項である。
根拠JSTQB Advanced Level テストアナリスト(CTAL-TA)シラバス Version4.0.J01 1.2.1節 テスト分析
テスト実行中にある手動テストで期待結果と異なる結果（不正）が観測され、テストアナリストが原因を分析したところ、テスト対象には欠陥がなく、テストデータの投入誤りが原因であることが判明した。この事象から読み取れる内容として適切なものはどれか。
- A不正が観測された場合、テスト対象には必ず欠陥が存在する。
- B不正の原因分析はテストアナリストの業務範囲外であり、開発担当者のみが行うべきである。
- C不正はテスト環境の問題によってのみ発生する。
- ✓不正は必ずしもテスト対象の欠陥に起因するとは限らず、テストデータの誤りなど他の原因によっても発生し得る。
解説
シラバスでは、不正はテスト対象の欠陥に起因する場合もあるが、事前条件の欠如、テストデータの誤り、テストスクリプトやテスト環境の欠陥、仕様の誤解など他の原因も考えられると説明されている。したがって選択肢1・3は誤りであり、原因分析はテストアナリストの典型的な作業の一つである。
根拠JSTQB Advanced Level テストアナリスト(CTAL-TA)シラバス Version4.0.J01 1.2.4節 テスト実行
あるテストアナリストは、テスト計画書で定義された終了基準をすべて満たすテストケースを設計し終えたが、残存リスクレベルとプロジェクトの予算制約を考慮し、さらに追加のテストケースを設計することにした。この判断の根拠として最も適切なものはどれか。
- Aハイレベルテストケースはローレベルテストケースの後に設計すべきであるため。
- Bテスト設計は特定のツールや技術に強く依存した形で実施すべきであるため。
- ✓テスト設計は、テスト計画書で定義された終了基準に加えて、残存リスクレベルやプロジェクト制約（予算や時間など）も、終了時期を示す要因となり得るため。
- Dテスト設計はテスト計画書の終了基準のみに基づいて判断すべきであり、他の要因を考慮すべきではないため。
解説
シラバスでは、十分なテストケースが設計されたかどうかはテスト計画書で定義された終了基準を用いて判断するが、残存リスクレベルやプロジェクト制約のような他の終了基準もテスト設計の終了時期を示す場合があると説明されている。選択肢1は順序が逆、選択肢2はツールに縛られないべきという記述と矛盾する。
根拠JSTQB Advanced Level テストアナリスト(CTAL-TA)シラバス Version4.0.J01 1.2.2節 テスト設計
テストマネジメントツールとテストデータマネジメントツールの違いに関する記述として正しいものはどれか。
- Aテストデータマネジメントツールはテストケースの進捗レポートやトレーサビリティマトリクスを提供し、テストマネジメントツールは機密データの保護を担う
- B両ツールはいずれも欠陥解決プロセスの記録・優先順位付け・モニタリングを主目的とする
- ✓テストマネジメントツールはテストウェアのリポジトリ提供やトレーサビリティ・進捗レポートを支援するのに対し、テストデータマネジメントツールは機密データの保護を含めテスト実行用データの作成・保守に特化する
- Dテストマネジメントツールはテスト環境の構成や可用性のマネジメントを行い、テストデータマネジメントツールは要件のバージョン管理を行う
解説
テストマネジメントツールはテストウェアのリポジトリ・トレーサビリティ・進捗レポートを支援するツールであり、テストデータマネジメントツールは機密データの保護を含めてテストデータを作成・保守するツールである。両者は目的が異なり、互換性はない。
根拠JSTQB Advanced Level テストアナリスト(CTAL-TA)シラバス 1.3.7 テストウェアのマネジメントに適用するツール
欠陥マネジメントツールと構成管理ツールの違いに関する記述として正しいものはどれか。
- A欠陥マネジメントツールはテスト環境の構成や可用性のマネジメントを行い、構成管理ツールは欠陥解決プロセスを記録する
- B両ツールはいずれも要件のバージョン管理を主目的とする
- C欠陥マネジメントツールはテストデータの機密性保護を担い、構成管理ツールはテストケースの進捗レポートを提供する
- ✓欠陥マネジメントツールは欠陥解決プロセスを記録・優先順位付け・モニタリングするのに対し、構成管理ツールはテスト環境の構成や可用性のマネジメントなど開発・リリース・運用プロセスにおけるテスト関連活動を促進する
解説
欠陥マネジメントツールは欠陥の記録・優先順位付け・モニタリングを担うのに対し、構成管理ツールはテスト環境の構成や可用性のマネジメントなど、開発・リリース・運用プロセス全体のテスト関連活動を促進するものであり、役割が異なる。
根拠JSTQB Advanced Level テストアナリスト(CTAL-TA)シラバス 1.3.7 テストウェアのマネジメントに適用するツール
欠陥マネジメントツールが支援する欠陥解決プロセスの一般的な順序として適切なものはどれか。
- A優先順位付け→記録→モニタリング
- ✓記録→優先順位付け→モニタリング
- Cモニタリング→記録→優先順位付け
- D優先順位付け→モニタリング→記録
解説
シラバスでは欠陥マネジメントツールは欠陥解決のプロセスを「記録、優先順位付け、モニタリングする」と記述されており、この順序が一般的な流れである。
根拠JSTQB Advanced Level テストアナリスト(CTAL-TA)シラバス 1.3.7 テストウェアのマネジメントに適用するツール