【ISTQB /JSTQB ALTM 3.0解説】Chapter 2「Managing the Product」サンプル問題解説|欠陥管理・メトリクスの理解を深めよう

JSTQB Advanced Level Test Management 3.0

ISTQB Advanced Level Test Management(テストマネージャ)Chapter 2では、

**「製品の管理(Managing the Product)」**というテーマのもと、欠陥管理やテストメトリクス、レポート作成など、テストマネージャに求められる重要スキルがまとめられています。

今回は、その第2章の総まとめとして紹介された**サンプル問題(Sample Questions)**をわかりやすく解説します。

本記事を読むことで、ISTQB試験で出題されやすい「シナリオ問題の読み方」と「正答を導く思考法」を身につけることができます。


📘 Question 1:メトリクスの選定

問題文

あなたはドキュメント駆動型(ウォーターフォール)開発モデルを用いた銀行システムのテストマネージャです。

チームは大規模で階層的。要件や技術は安定しており、品質・セキュリティ規制への準拠が求められています。

この状況で、ステークホルダーが意思決定に役立つテストメトリクスとして最も適切なものはどれでしょうか?


選択肢

A. リスク、欠陥、進捗、カバレッジ、コスト、テスト労力に関するメトリクス

B. 欠陥、進捗、カバレッジ、コードカバレッジに関するメトリクス

C. プロダクトリスク、欠陥、進捗、カバレッジ、環境構成カバレッジに関するメトリクス

D. 欠陥、進捗、カバレッジ、未テスト要素の残コストに関するメトリクス


解説

  • コードカバレッジや環境構成カバレッジは**主要メトリクス(Primary Dimensions)**ではありません。

  • 「未テスト要素の残コスト」は概念的に不明確。

  • Aはすべての主要メトリクス(リスク・欠陥・進捗・カバレッジ・コスト・労力)を網羅しており、最も包括的。

正解:A


ポイント

大規模組織では報告を多角的に行う必要があります。

1つの視点(例:欠陥数)だけでは経営判断につながらないため、全主要メトリクスのバランスが重要です。


🧭 Question 2:欠陥ライフサイクルの状態識別

問題文

下図のような欠陥ワークフローのうち、状態XとYを適切に命名してください。

  • Xは「Open → X → Open」および「X → Closed」の経路を持つ

  • Yは「Open → Y → In Progress → Y」と遷移できる


選択肢

A. X=Retested、Y=Reopened

B. X=Rejected、Y=Clarification

C. X=Duplicate、Y=Terminated

D. X=Fixed、Y=Rejected


解説

  • Retestedは「開発側で修正済み」の後に行われるためXの位置に不適。

  • DuplicateはIn Progress後に判断されるため位置的に不自然。

  • Terminatedは最終状態にのみ使用される。

  • 「Open→Rejected→Closed」および「Open→Clarification→In Progress→Clarification」の流れが最も自然。

正解:B(X=Rejected、Y=Clarification)


ポイント

ISTQBでは、欠陥状態の一貫性と明確なトランジションを重視します。

「却下(Rejected)」と「要確認(Clarification)」の違いを明確に理解しましょう。


⚙️ Question 3:アジャイルチームでの欠陥報告判断

問題文

あなたはアジャイルチームのテスターです。

第3スプリントで、ログイン機能(第1スプリントで開発)に不具合を発見しました。

この機能は外部のIDプロバイダー(IDP)チームと共同で開発されています。

次のうち、欠陥報告を作成しない正当な理由はどれでしょうか?


選択肢

A. 開発者が次週まで修正に着手できないため

B. チームの開発者にまず確認する必要があるため

C. IDPチームとの連携が必要なため

D. プロダクトオーナーが低優先度と判断し、次のイテレーションで修正すると決めたため


解説

  • A・Dは「後日修正」案件であり、追跡のため報告書が必要

  • Cも外部連携が関係するため文書化が必要。

  • Bのみ、「まず開発者と口頭確認し、誤検知でないか確認してから報告する」ことが合理的。

正解:B


ポイント

アジャイルでは「ドキュメントより対話を重視」しますが、再発防止・共有が必要な場合は必ず記録します。

軽視すべきは「書類」ではなく「無駄な書類」です。


🤝 Question 4:第三者(外部ベンダー)への欠陥報告

問題文

あなたのチームは外部ベンダーが開発したソフトウェアのシステムテストを実施中です。

ベンダーから「欠陥報告書の内容が不十分で再現できない」と苦情を受けました。

次のうち、報告に欠けていた可能性が高い情報を2つ選びなさい。


選択肢

A. プロジェクト活動内容(例:テストレベル)

B. 再現手順と実際/期待結果

C. 修正の優先度(Priority)

D. 技術的欠陥タイプ(例:構文/機能/UI)

E. 欠陥が発生した開発ライフサイクル段階


解説

  • A・Eはすでに明示(システムテスト中)なので不要。

  • Dは分析用情報であり、修正には直結しない。

  • BとCは、外部組織に欠陥を伝達するうえで最重要情報

正解:B と C


ポイント

第三者チームとの連携では、「再現手順」と「修正優先度」を必ず明記。

再現できない欠陥報告は、修正作業を遅延させる最大の要因です。


🏁 Chapter 2 試験対策まとめ

学習観点

試験・実務での重要ポイント

欠陥ライフサイクル

状態遷移を正しく理解し、再現性を重視する

メトリクス管理

リスク・欠陥・進捗・コストなど全方位で可視化

アジャイル判断

無駄な報告は避け、対話と効率を両立

外部連携

再現手順+優先度の明示は必須

コメント

タイトルとURLをコピーしました