テストピラミッド・リスク分析・品質メトリクスをマスターしよう
本記事では、ISTQB Foundation（CTFL）試験サンプル問題（Part #13）A21〜A26を解説します。
試験でも頻出の「テストピラミッド」「リスク分析」「品質メトリクス」など、
基礎ながら理解を深めることで得点アップにつながる重要テーマを扱います。
🧩 質問A21：テストピラミッドに関して正しい説明はどれか？
問題文
次のうち、テストピラミッドに関して正しい記述はどれか？
選択肢
A. 下位レベルのテストを多く実施することを重視している
B. 各下位レベルのテストはシステム全体の大部分をカバーする
C. テストピラミッドはSDLC全体でのテストタイプの分布を示す
D. 自動化テストの構築には影響しない
✅ 正解：A
💡 解説
テストピラミッドとは、テストレベルのバランスを示すモデルです。
UIテスト（少ない）
——————-
API/統合テスト（中間）
——————-
ユニットテスト（最も多い）
-
上層（UIテスト）：実行コストが高く、壊れやすい
-
下層（ユニットテスト）：高速で自動化しやすい
そのため、下位レベルで多くのテストを実施し、上位は最小限にすることが理想です。
🔍 具体例
Webアプリの「ログイン機能」では：
-
ユニットテスト：パスワード検証ロジックを100件
-
APIテスト：ログインAPI応答を20件
-
UIテスト：画面操作の確認を5件
ピラミッドの形でバランスを取ることで、保守性と効率を両立できます。
⚖️ 質問A22：リスク影響度が「非常に高い」と判断された場合、発生確率について言えることは？
問題文
チームは「顧客に対する割引が過大になる」というリスクの影響度を「非常に高い」と評価しました。
このとき、リスクの発生確率について言えることはどれでしょうか？
選択肢
A. 影響度が高いリスクは、発生確率も高い
B. 影響度が高いリスクは、発生確率が低い
C. 影響度と発生確率は独立している
D. 影響度が高ければ、発生確率を定義する必要はない
✅ 正解：C
💡 解説
影響度（Impact） と 発生確率（Likelihood） は独立した軸です。
影響が大きくても発生確率が低い場合もあります。
🔍 具体例
|
ケース |
影響度 |
発生確率 |
例 |
|---|---|---|---|
|
サーバ全停止 |
高 |
低 |
まれに起こるが被害甚大 |
|
軽微なUI不具合 |
低 |
高 |
頻繁に起こるが影響は小 |
したがって、影響度の高さだけで発生確率を判断することはできません。
🏗 質問A23：次のうち「プロジェクトリスク」に分類されるものはどれか？
問題文
次のリスクのうち、プロジェクトリスクに該当するものを選びなさい。
選択肢
-
経験豊富なテスターが他のプロジェクトに異動した
-
システムが安全規格に準拠していない
-
システムの応答時間が要件を満たしていない
-
ステークホルダーの期待が不正確である
-
障害者がシステムを利用しにくい
✅ 正解：1 と 4
💡 解説
リスクは2種類に分類されます：
|
リスクの種類 |
内容例 |
|---|---|
|
プロジェクトリスク |
メンバー移動、スケジュール遅延、予算不足、期待のずれ |
|
プロダクトリスク |
機能不備、性能不足、品質低下 |
🔍 具体例
-
1 → 人的リソース問題（プロジェクトリスク）
-
4 → ステークホルダー間の認識差（プロジェクトリスク）
-
他はシステム品質に関するリスク（プロダクトリスク）
🔬 質問A24：プロダクトリスク分析がテスト範囲に影響を与える例はどれか？
問題文
プロダクトリスク分析がテストの網羅性とスコープに影響を与える例を選びなさい。
選択肢
A. テストマネージャが毎日リスクを報告し、リリース判断に役立てる
B. オープンソースDBのサポート不足が判明し、システムをDBと統合することにした
C. 定量的リスク分析の結果、残存リスクを報告した
D. 高い性能リスクが判明し、詳細な性能テストを開発初期に実施することにした
✅ 正解：D
💡 解説
リスク分析の結果は「どの領域をどれだけテストするか」の判断に直結します。
リスクが高い領域は、より早期・詳細にテストを行うのが原則です。
🔍 具体例
自動車のADASソフトウェアで「ブレーキ制御の性能リスク」が高いと判明した場合、
リリース前ではなく開発初期に性能テストを重点的に実施します。
これにより、重大不具合を早期に検出し修正コストを削減できます。
📊 質問A25：テスト対象の品質レベルを示す一般的なメトリクスはどれか（2つ選択）
問題文
テスト対象の品質レベルを報告する際に使用される一般的なメトリクスを2つ選びなさい。
選択肢
A. システムテスト中に検出された欠陥数
B. テスト設計工数 ÷ 設計済みテストケース数
C. 実行したテスト手順の数
D. 欠陥数 ÷ ワークプロダクトの規模
E. 不具合修正に要した時間
✅ 正解：A と D
💡 解説
品質を測るには、欠陥に基づくメトリクスが有効です。
|
メトリクス |
内容 |
意味 |
|---|---|---|
|
欠陥数 |
発見された不具合件数 |
品質レベルの直接的な指標 |
|
欠陥密度（Defect Density） |
欠陥数 ÷ コード量（例：1000LOCあたり） |
製品の品質比較に便利 |
一方、工数や修正時間は品質そのものを示す指標ではありません。
🗂 質問A26：ビジネス担当者にとって最も役立たないテスト進捗報告の内容はどれか？
問題文
テスト進捗報告書に含まれる次の情報のうち、ビジネス担当者にとって最も役立たないものはどれか？
選択肢
A. テストの障害要因（impediments）
B. テスト進捗の概要
C. ブランチカバレッジ達成率
D. テスト中に新たに発見されたリスク
✅ 正解：C
💡 解説
ビジネス担当者は「進捗」「リスク」「問題点」には関心がありますが、
ブランチカバレッジのような技術的指標は関心が薄いです。
🔍 比較表
|
項目 |
ビジネス視点での有用性 |
|---|---|
|
A. 障害要因 |
✅ 高い（リリース遅延の原因を把握） |
|
B. 進捗概要 |
✅ 高い（進行状況の可視化） |
|
D. 新リスク |
✅ 高い（対応計画を検討できる） |
|
C. ブランチカバレッジ |
❌ 技術的で判断材料になりにくい |
🧭 まとめ：Part #13の学びポイント
|
テーマ |
学びの要点 |
|---|---|
|
テストピラミッド |
下位レベル（ユニット・API）を重視し、UIテストを最小限に |
|
リスク分析 |
影響度と発生確率は独立軸として考える |
|
リスク分類 |
プロジェクトリスクとプロダクトリスクを明確に区別 |
|
リスクベースドテスト |
高リスク領域を早期・重点的にテスト |
|
品質メトリクス |
欠陥数・欠陥密度を活用して品質を可視化 |
|
進捗報告 |
技術指標よりもビジネスに関連する情報を重視 |
コメント