ISTQB Foundation（CTFL）試験の頻出テーマを扱ったこのシリーズのPart #28では、
「テスト技法」や「チェックリストテストのカバレッジ」「ATDD（Acceptance Test Driven Development）」「テスト計画の目的」など、
試験に直結する重要概念を5問ピックアップしています。
❓質問26：次のリストを使用してテストしているテスターが採用しているテスト技法はどれ？
リスト内容：
-
正しい入力が受け入れられない
-
誤った入力が受け入れられる
-
出力フォーマットが間違っている
-
ゼロによる除算（Division by zero）
選択肢：
A. 探索的テスト（Exploratory Testing）
B. チェックリストベーステスト（Checklist-Based Testing）
C. 境界値分析（Boundary Value Analysis）
D. フォールトアタック（Fault Attack）
✅ 正解：D. フォールトアタック（Fault Attack）
💡解説：
このリストは、システムの欠陥（フォールト）を意図的に引き出すための典型的な攻撃的テストアプローチです。
「ゼロによる除算」や「誤った入力の受け入れ」など、潜在的な欠陥を想定してテストケースを設計する点がポイントです。
🔍 具体例：
たとえば電卓アプリをテストするとき、普通は「2＋3＝5」のような正常値を試しますが、Fault Attackでは「0で割る」「空欄を入力」「桁あふれを起こす」など異常動作を狙った入力を行います。
❓質問27：チェックリストベーステストによってカバレッジが向上する理由を最もよく表しているのはどれ？
選択肢：
A. チェックリスト項目を詳細化し、テストケースに直接落とし込めるから
B. チェックリストを自動化し、実行ごとにカバレッジが増えるから
C. 各チェックリスト項目を独立してテストすることで広範囲をカバーできるから
D. 同じチェックリスト項目を使っても、テスターごとに異なる方法で実行されるから
✅ 正解：D. 同じチェックリストでもテスターが異なれば、異なる方法で実行するため
💡解説：
チェックリストテストは形式的な手順がないため、テスターの経験や観点の違いが自然に多様なテストを生み出します。
この結果、テストカバレッジが向上します。
🔍 具体例：
たとえば「ログイン機能を確認」というチェックリスト項目があった場合、
あるテスターは「正しいID・パスワード」を確認し、別のテスターは「空欄」「特殊文字」「大文字小文字」などを試す可能性があります。
このように複数の観点が自然にカバーされるのがチェックリストベーステストの強みです。
❓質問28：シナリオ指向の受け入れ基準（Scenario-oriented Acceptance Criteria）の最も良い例はどれ？
選択肢：
A. 「ユーザーはアカウント削除を要求した場合、すべての関連データを削除できなければならない」
B. 「顧客が商品をカートに追加してチェックアウトに進むと、ログインまたは新規登録を促される」
C. 「商品名を含む場合、Falseを返す」
D. 「Webサイトは特定の規格に準拠していなければならない」
✅ 正解：B. 顧客がカートに商品を追加してチェックアウトに進むとログインまたは登録を促される
💡解説：
シナリオ指向の受け入れ基準とは、エンドユーザーの操作シナリオに基づいて要件を定義することです。
単なる要件ではなく、**ユーザーの行動の流れ（When → Then構文など）**で記述されているものが正しい形式です。
🔍 具体例：
「顧客が商品をカートに入れて購入しようとした時、ログイン画面に遷移する」などは実際の利用シナリオを示しています。
一方、「サイトはSSL対応であること」は技術要件であり、シナリオとは言えません。
❓質問29：ATDD（Acceptance Test Driven Development）で、次のユーザーストーリーの受け入れ基準3をテストする最も適切なテストケースはどれ？
ユーザーストーリー：
「通常ユーザーまたは特別ユーザーとして、電子フロアカードで特定の階層にアクセスできるようにしたい」
受け入れ基準：
-
通常ユーザーは1〜3階にアクセスできる
-
4階は特別ユーザーのみアクセス可能
-
特別ユーザーは通常ユーザーのアクセス権をすべて持つ
選択肢：
A. 通常ユーザーが1〜3階にアクセスできることを確認する
B. 通常ユーザーが4階にアクセスできないことを確認する
C. 特別ユーザーが5階にアクセスできることを確認する
D. 特別ユーザーが1〜3階にアクセスできることを確認する
✅ 正解：D. 特別ユーザーが1〜3階にアクセスできることを確認する
💡解説：
受け入れ基準3では「特別ユーザーは通常ユーザーのアクセス権をすべて持つ」とあります。
したがって、特別ユーザーが1〜3階にもアクセスできるかを確認するのが正しいテストです。
🔍 具体例：
-
特別ユーザー → 1〜4階すべてアクセス可
-
通常ユーザー → 1〜3階のみ
→ この関係性を検証するテストがDです。
❓質問30：次のうち、テスト計画書（Test Plan）の目的ではないものはどれ？
選択肢：
A. コンポーネントテストやコンポーネント統合テストのテストデータと期待結果を定義する
B. コンポーネントテストレベルの終了基準として、100%ステートメントカバレッジを達成することを定義する
C. テスト進捗レポートの項目や形式を記述する
D. テスト戦略に反してシステム統合テストを除外する理由を説明する
✅ 正解：A. コンポーネントテストのデータや期待結果を詳細に定義する
💡解説：
テスト計画書は**「全体方針」「目的」「範囲」「スケジュール」などの上位文書であり、
個々のテストケースレベルの詳細（テストデータや期待結果）は記載しません。
Aの内容はテスト設計書（Test Case Specification）**に記述されるべき内容です。
🎯まとめ
|
問題番号 |
トピック |
正解 |
|---|---|---|
|
Q26 |
Fault Attack（欠陥攻撃テスト） |
D |
|
Q27 |
チェックリストベーステストのカバレッジ |
D |
|
Q28 |
シナリオ指向の受け入れ基準 |
B |
|
Q29 |
ATDD（受け入れテスト駆動開発） |
D |
|
Q30 |
テスト計画の目的 |
A |
これらの問題はISTQB Foundation試験の中でも試験頻出トピックであり、
それぞれの用語と適用シーンを具体的に理解しておくことが合格への近道です。
コメント