ISTQB Foundation（CTFL）試験の準備をしている方へ。
今回の記事では、「Exam Questions and Answers Explained – Part #12」動画の内容をもとに、
試験によく出る 5つの重要テーマ をわかりやすく解説します。
✅ 質問A16：Branch Testing（分岐網羅）の正しい理解
問題文：
Branch Testing（分岐網羅）について、正しい説明はどれか？
選択肢：
A. 無条件分岐だけを含むプログラムでは、テストを実行せずに100%分岐網羅を達成できる。
B. 全ての無条件分岐を実行すれば100%分岐網羅が達成される。
C. 100%ステートメント網羅を達成すれば、100%分岐網羅も達成される。
D. 100%分岐網羅を達成すれば、各分岐文のすべての結果（True/False）が実行されている。
✅ 正解：D
💡 解説：
分岐網羅（Branch Coverage）は、すべての条件の「真(True)」と「偽(False)」の両方をテストすることを目的とします。
つまり、「if文」「switch文」などのすべての分岐パスを実行して初めて100%達成されます。
🔍 補足：
-
100% Branch Coverage → 100% Statement Coverageを含む
-
しかし逆（Statement → Branch）は成立しません！
🎯 具体例：
if score > 80:
print(“Pass”)
else:
print(“Fail”)
このコードでは、
-
score=90（Trueパス）
-
score=50（Falseパス）
の両方をテストして、初めて100% Branch Coverageを達成できます。
✅ 質問A17：UIテストとチェックリストベース手法
問題文：
銀行アプリの各画面と各項目を、ユーザーインターフェイスのベストプラクティス一覧に基づいて評価する。
このテスト手法はどのカテゴリーに分類されるか？
🔸選択肢：
A. 探索的テスト（Exploratory Testing）
B. エラー推測（Error Guessing）
C. チェックリストベーステスティング（Checklist-based Testing）
D. ブラックボックステスティング（Black-box Testing）
✅ 正解：C. チェックリストベーステスティング（Checklist-based Testing）
💡 解説：
与えられた「一般的なチェックリスト」を使ってUIを評価する場合、
それはチェックリストベーステスト技法に分類されます。
これは、ユーザビリティ・アクセシビリティ・デザイン整合性などを体系的に評価するのに有効です。
🎯 具体例：
-
ボタンのサイズが小さすぎないか
-
カラーコントラストが十分か
-
入力エラー時に適切なメッセージが表示されるか
→ こうした「チェック項目に基づく」確認作業は、チェックリストベーステストです。
✅ 質問A18：ユーザーストーリー作成における協働（Collaborative Approach）
問題文：
ユーザーストーリーの「協働的な作成方法」を最もよく表しているのはどれか？
選択肢（要約）：
A. テスターと開発者が作り、ビジネス担当が承認する。
B. ビジネス担当、開発者、テスターが一緒に作成する。
C. ビジネス担当が作り、開発者とテスターが検証する。
D. ユーザーストーリーは独立・交渉可能・価値ある・見積可能・小さく・テスト可能である。
✅ 正解：B
💡 解説：
アジャイルでは「3 Amigos（スリー・アミーゴス）」という考え方が有名です。
これは ビジネス担当者（POなど）・開発者・テスター が一緒にユーザーストーリーを作成・議論するという協働の形です。
🤝 コラボレーションの目的：
-
共通理解の形成
-
テスト観点の早期抽出
-
誤解の防止
✅ 質問A19：テスト計画書における「テストアプローチ」部分
問題文：
テスト計画の一部に「クリティカルなコンポーネントについて100%のBranch Coverageを達成する」と記載がある。
この内容は、テスト計画のどのセクションに該当するか？
🔸選択肢：
A. コミュニケーション（Communication）
B. リスク登録簿（Risk Register）
C. テストのコンテキスト（Context of Testing）
D. テストアプローチ（Test Approach）
✅ 正解：D. テストアプローチ（Test Approach）
💡 解説：
テストアプローチでは、
-
どのレベルのテストを行うか（例：コンポーネントテスト、統合テスト）
-
どのカバレッジ基準を適用するか（例：100% Branch Coverage）
などを定義します。
⚙️ 例：
「コンポーネントレベルでは条件網羅を使用し、クリティカルモジュールは分岐網羅を100%達成する」
→ このような記述は“テストアプローチ”に含まれます。
✅ 質問A20：アジャイルにおけるプランニングポーカー（Planning Poker）
問題文：
チームでプランニングポーカーを実施。2回の投票で合意に至らず、3回目でも差が小さいため「最も票が多い数値を採用する」ルールを適用する。
次にとるべき最適なステップは？
🔸選択肢：
A. プロダクトオーナーが最終的な見積りを決定する。
B. 最も多く票を得た「13」を最終見積りとして採用する。
C. さらなる行動は不要。すでに合意に達している。
D. 合意が得られなかったため、新機能を今回のリリースから除外する。
✅ 正解：B. 票が最も多い「13」を最終見積りとして採用する
💡 解説：
プランニングポーカーでは、チーム全員が合意できない場合でも、
**「最も多い票を得た値」**を採用するルールを定めておくことがあります。
⚠️ 間違い例：
-
POが独断で決める（×）
-
合意できないので機能を削除する（×）
🎯 具体例：
|
メンバー |
Round 1 |
Round 2 |
Round 3 |
|---|---|---|---|
|
A |
8 |
13 |
13 |
|
B |
13 |
13 |
13 |
|
C |
8 |
8 |
8 |
|
D |
13 |
13 |
13 |
|
E |
13 |
13 |
13 |
|
F |
13 |
8 |
13 |
|
G |
13 |
13 |
13 |
→ 最も多い「13」を最終見積もりとして採用するのが正解です。
🧭 試験対策のポイントまとめ
|
テーマ |
学ぶべき要点 |
試験での落とし穴 |
|---|---|---|
|
Branch Testing |
真偽両方の分岐を実行して初めて100%達成 |
ステートメント網羅と混同しない |
|
チェックリストベース |
一般的なベストプラクティスに沿ったUI評価 |
探索的テストと混同しない |
|
ユーザーストーリー |
ビジネス・開発・テストの三者協働 |
「誰かが作って他が承認する」ではない |
|
テストアプローチ |
どのテストレベル・技法を使うかを定義 |
「リスク」や「コンテキスト」と混同しない |
|
プランニングポーカー |
合意に至らない場合のルール運用 |
POの独断ではない |
🧩 まとめ
このPart #12では、ISTQB Foundation試験で頻出のテーマである
「カバレッジ基準・UIテスト・アジャイルの協働・テストアプローチ・プランニングポーカー」を学びました。
特に、問題文中にヒントが隠されているケースが多いので、
**「質問を丁寧に読む」**ことが合格への近道です。
コメント