ISTQB Foundation Level 4.0のChapter 4「Test Analysis and Design」では、多くのテスト設計技法を学びます。
本記事では、YouTubeチャンネル TM Square の講座内容をもとに、Chapter 4に関する模擬問題を分かりやすく解説します。
試験対策だけでなく、実務で「テスト設計力」を高めるためにも役立つ内容です。
🧩 問題1：経験ベースのテスト技法（Experience-Based Techniques）
質問：
次のうち、経験ベースのテスト技法の特徴として正しいものはどれですか？
選択肢：
A. 詳細設計情報に基づいてテストケースを作成する
B. コードのインターフェース部分を用いてカバレッジを測定する
C. テスターのソフトウェア知識と業務ドメイン知識に大きく依存する
D. テストケースを用いて要求からの逸脱を特定する
✅ 正解：C
「テスターの知識と経験を活用する」ことが経験ベース技法の本質です。
💡 解説：
経験ベースのテスト技法とは、テスターの過去の経験・直感・ドメイン知識に基づいてテストを設計する方法です。
代表的な手法としては以下があります。
-
エラー推測（Error Guessing）：過去に起こった典型的なバグを想定する
-
探索的テスト（Exploratory Testing）：事前に決めすぎず、実際に触って問題を見つける
-
チェックリストベースドテスト（Checklist-Based Testing）：過去の不具合や経験をリスト化して再利用
🧠 具体例：
たとえば、銀行システムのログイン画面をテストする場合、
-
ベテランテスターは「空欄」「全角文字」「特殊文字」「SQLインジェクション」などを直感的に試します。
-
これは過去の知識や経験をもとにした「勘と洞察」に基づくテストです。
これがまさに、経験ベースのテスト技法です。
🧮 問題2：100％ステートメントカバレッジを達成したときの意味
質問：
テストスイートが100％のステートメントカバレッジを達成した場合、どのような結果を意味しますか？
選択肢：
A. コード内のすべての命令が少なくとも1回実行された
B. より多くのテストケースを追加しても同じカバレッジになる
C. コード内のすべてのパスが1回ずつ実行された
D. 入力のすべての組み合わせを少なくとも1回テストした
✅ 正解：A
「すべての命令文（statement）が少なくとも1度は実行された」ことを意味します。
💡 解説：
-
ステートメントカバレッジとは、ソースコードの命令文（statement）がどれだけ実行されたかを示す指標です。
-
100％達成しても「バグがない」とは限りません。
例えば、条件分岐の真偽両方をテストしていなければ、ブランチカバレッジは不十分です。
🧠 具体例：
以下のようなコードを考えましょう。
if x > 10:
print(“A”)
else:
print(“B”)
-
入力値 x = 15 でテスト → 「A」が実行される（else文は実行されない）
-
この場合、ステートメントカバレッジは100％ではなく**50％**です。
-
x = 5 もテストして「B」も実行されれば、100％になります。
🚫 よくある誤解：
-
「100％カバレッジ＝バグがない」ではありません。
-
ループや条件分岐の全パスを網羅するのは不可能（ISTQB原則：完全なテストは不可能）です。
🧾 問題3：受け入れ基準（Acceptance Criteria）の記述方法
質問：
受け入れ基準（Acceptance Criteria）は、どのように記述するのが最も適切ですか？
選択肢：
A. レトロスペクティブでステークホルダーのニーズを特定する
B. 「Given-When-Then」形式でテスト条件を記述する
C. 口頭で伝えて誤解を減らす
D. テスト計画書内でリスクを文書化する
✅ 正解：B
「Given（前提）- When（条件）- Then（結果）」の形式で書くのがベストです。
💡 解説：
受け入れ基準（Acceptance Criteria）は、ユーザーストーリーが完了したと見なす条件です。
誰が読んでも同じ理解になるよう、明確かつ具体的に記述する必要があります。
📘 具体例：
ユーザーストーリー：
「ユーザーとして、正しいIDとパスワードでログインできるようにしたい」
受け入れ基準（Given-When-Then形式）：
Given ユーザーがログインページを開いている
When 正しいユーザーIDとパスワードを入力する
Then ホーム画面が表示される
このように書くことで、開発者・テスター・PO（プロダクトオーナー）全員が同じ理解を共有できます。
🚫 NG例：
-
「ログインができること」だけでは曖昧すぎる
-
「テスト計画書にまとめる」「口頭で伝える」は管理面では良くても、受け入れ条件の記述方法としては不適切
🎯 まとめ：Chapter 4の出題傾向と学びのポイント
|
テーマ |
出題されやすいポイント |
対策 |
|---|---|---|
|
経験ベース技法 |
テスターの直感・過去の知識の活用 |
実務でのバグ経験を振り返る |
|
カバレッジ分析 |
ステートメント・ブランチの違い |
コード例を使って実践理解 |
|
受け入れ基準 |
Given-When-Then形式 |
実際のユーザーストーリーで練習 |
📚 学習のヒント
-
ISTQB試験では「定義を正確に覚える」よりも、概念を理解して応用できるかが重要です。
-
選択肢の「正しいもの」だけでなく、「最も適切なもの（best）」を選ぶ問題にも注意しましょう。
🏁 まとめ
Chapter 4では、テスト設計技法の理解と適用力が問われます。
経験に頼るだけでなく、論理的な根拠をもって判断することがISTQB合格の鍵です。
🔍 次のステップ：
「Chapter 5 – Test Management」へ進む前に、今回の模擬問題を何度も復習しておきましょう。
コメント