それぞれの問題の選択肢を丁寧に確認しながら、なぜその答えが正解なのかを実務的な観点から説明していきます。

質問1：DevOpsを導入する際に最も起こりやすい課題はどれ？

設問：

次のうち、DevOpsを実装する際に最も起こりやすい課題はどれですか？

選択肢：

A. 非機能的品質特性が見落とされないようにすること

B. 継続的に変化するテスト環境の管理

C. 経験豊富なマニュアルテスターの確保

D. 配信パイプラインの一部としてテスト自動化を構築すること

正解： D. 配信パイプラインの一部としてテスト自動化を構築すること

解説：

DevOpsの導入時に最も大きな課題の一つが、テスト自動化をパイプラインに統合することです。

特に、開発・テスト・デプロイを高速に繰り返す環境では、自動化テストの設計・実装・メンテナンスが難しくなります。

具体例：

CI/CD環境でビルドごとに自動テストを走らせる際、テストデータや環境依存の不具合により、自動化が止まってしまうことがあります。

このような場合、テストスクリプトの安定性と環境管理が課題になります。

質問2：レトロスペクティブ（振り返り）を最もよく表すものはどれ？

設問：

次のうち、アジャイル開発における「レトロスペクティブ（振り返り）」を最もよく説明しているものはどれですか？

選択肢：

A. チームメンバーの貢献度を確認する場

B. 成功した活動を特定し、今後も維持するための機会を提供する場

C. 管理層や顧客への不満を表明する場

D. 次のイテレーション計画や技術的な意思決定を行う場

正解： B. 成功した活動を特定し、今後も維持するための機会を提供する場

解説：

レトロスペクティブは「うまくいったこと・改善すべきこと」をチーム全体で振り返るミーティングです。

目的は“責任追及”ではなく“継続的改善”。

次のスプリントで成功事例を活かし、課題を改善することを目的とします。

具体例：

前回のスプリントで自動テストのカバレッジが向上したなら、その実施方法を標準化して継続します。

逆に、レビュー時間が不足していた場合は、スプリント計画時にリソースを再配分します。

質問3：機能テストの一環として最も実施される可能性が高いテストはどれ？

設問：

次のうち、機能テストの一部として最も実施される可能性が高いものはどれですか？

選択肢：

A. ソート関数がリストを昇順に並べ替えるかを確認するテスト

B. ソート関数が1秒以内に処理を完了するかを確認するテスト

C. ソート関数を容易に変更できるかを確認するテスト

D. ソート関数が32ビットから64ビット環境に移行しても動作するかを確認するテスト

正解： A. ソート関数がリストを昇順に並べ替えるかを確認するテスト

解説：

機能テストは、仕様どおりに機能が動作するかを確認します。

一方、性能・移植性・使いやすさなどは非機能テストの範囲です。

選択肢Aは典型的な機能テストの例です。

具体例：

入力データ [5, 2, 9] に対して、出力が [2, 5, 9] であれば、機能要件どおりに動作していると判断します。

質問4：保守テストを実施するきっかけ（トリガー）として最も可能性が高いのはどれ？

設問：

次のうち、通貨交換システムで保守テストを行うきっかけとなる可能性が最も高いのはどれですか？

選択肢：

A. 開発者がシステム変更が難しいと報告し、テスターがそれを検証したいと考えた

B. 返金機能が正しく金額を返さなかったため、システムから削除された

C. 新しい顧客ロイヤルティ機能の開発が開始された

D. 通貨取引で英語と現地言語の両方をサポートできるよう設定が変更された

正解： B. 返金機能が正しく金額を返さなかったため、システムから削除された

解説：

保守テスト（Maintenance Testing）は、既存システムに変更が加えられた際の確認テストです。

機能追加や削除・修正が行われた場合、その影響を確認する目的で実施されます。

具体例：

返金機能を削除した場合、他の会計処理や顧客履歴への影響をテストします。

これは典型的な「回帰テスト（Regression Testing）」を含む保守テストです。

質問5：静的テストでは確認できないものはどれ？

設問：

次のうち、静的テストでは確認できないものはどれですか？

選択肢：

A. 契約書（Contract）

B. テスト計画書

C. 暗号化されたコード（Encrypted Code）

D. テストチャーター

正解： C. 暗号化されたコード（Encrypted Code）

解説：

静的テスト（Static Testing）は、プログラムを実行せずにレビューや解析を行う手法です。

ソースコード、テスト設計書、仕様書などを対象としますが、暗号化されたコードは内容が読めないため、静的解析できません。

具体例：

コードの内容が暗号化や圧縮によって可読不能な場合、コードレビューではロジックや不具合を検出できません。

まとめ

まとめ：学習のポイント

• DevOpsでは「自動化」が最大の課題。CI/CDパイプラインを理解しておく。

• レトロスペクティブの目的は「改善の継続」。責任追及の場ではない。

• 機能テストと非機能テストの違いを明確に区別する。

• 保守テストはシステム変更後の影響確認のために行う。

• 静的テストはコードを実行しない解析。暗号化データは対象外。

徹底攻略 JSTQB Foundation教科書＆問題集 シラバス2023対応 [ 梅田 弘之 ]

posted with カエレバ

楽天市場

Amazon

試験の理解を深めたい方や、実務にも活かせるテストの考え方を学びたい方におすすめの内容です。

質問6：テストマネジメントの役割として最もふさわしいタスクはどれ？

問題文：

次のうち、テストマネジメントの役割を担う人が最も行う可能性が高いタスクはどれですか？

選択肢：

A. テストベースやテスト対象を評価する

B. テスト環境の要件を定義する

C. テスト対象のテスト容易性を評価する

D. テスト完了報告書（Test Completion Report）を作成する

正解： ✅ D. テスト完了報告書を作成する

解説：

テストマネージャーの主な役割は、テスト活動の計画、管理、進捗報告、完了報告などを行うことです。

実際にテストケースを設計したり、環境構築を担当するのはテスターやテストアナリストの仕事です。

具体例：

テストマネージャーは「テストの進捗」「不具合件数」「カバレッジ率」などをまとめた完了報告書を関係者に提出します。

質問7：Whole Team Approach（チーム全体アプローチ）の利点はどれ？

問題文：

次のうち、Whole Team Approachの利点として最も適切なものはどれですか？

選択肢：

A. チームメンバー間のコミュニケーションが改善される

B. 品質に対する個々の責任が減少する

C. ユーザーへの納品スピードが速くなる

D. 外部ビジネスユーザーとの協力が減る

正解： ✅ A. チームメンバー間のコミュニケーションが改善される

解説：

Whole Team Approach（全員参加型テスト）は、開発者・テスター・PO（プロダクトオーナー）など全員が品質に責任を持つ考え方です。

これにより、チーム内の連携が強まり、バグの早期発見や共通理解が進みます。

具体例：

アジャイルチームでは、スプリントプランニングの段階からテスターも参加し、仕様理解やテスト観点を共有します。

質問8：テストの独立性に関する「利点」として正しいものはどれ？

問題文：

次のリストは、テストの独立性に関する利点と欠点を混ぜたものです。

この中で、利点に分類されるものはどれでしょうか？

選択肢：

1. テスターは開発者とは異なる場所で作業している。

2. テスターは開発者がコードを書く際の前提を疑う。

3. テスターと開発者の間に対立的な関係が生まれる。

4. 開発者はテスターが品質に責任を持つと考える。

5. テスターは開発者とは異なるバイアス（思い込み）を持っている。

正解： ✅ 2番と5番

解説：

テストの独立性とは、開発者以外の立場でテストを行うことで、客観的な視点から品質を確認できるという考え方です。

• 2番の利点：開発者の思い込みを見抜くことで、潜在的な不具合を発見できる。

• 5番の利点：異なる視点から評価できるため、バイアスを排除できる。

具体例：

開発者が「この画面では必ず数値が入力される」と思い込んでいても、テスターが「文字を入力した場合」を試すことで欠陥を発見する、など。

質問9：すべての開発ライフサイクルで適用できる「良いテストプラクティス」はどれ？

問題文：

すべてのソフトウェア開発ライフサイクルに共通して適用できる、良いテストプラクティスはどれですか？

選択肢：

A. 各テストレベルには明確で個別のテスト目的がある

B. 各テストレベルのテスト実行は対応する開発フェーズ中に開始するべき

C. ドラフト仕様が出たらすぐにテスト設計を始めるべき

D. 動的テスト活動には常に対応する静的テスト活動がある

正解： ✅ A. 各テストレベルには明確で個別のテスト目的がある

解説：

テストは「どの段階（レベル）で」「何を確認するか」が明確であることが重要です。

たとえば、

• 単体テスト：コード単位の動作確認

• 結合テスト：モジュール間のインターフェース確認

• 受け入れテスト：ユーザー視点でのビジネス要件確認

といった具合に、それぞれ目的を分けて実施します。

具体例：

結合テストでUIの見た目を確認するのは不適切です。それは受け入れテストの目的です。

質問10：テストファーストアプローチ（Test First Approach）の例はどれ？

問題文：

次のうち、Test First Approach（テストファーストアプローチ）の例として正しいものはどれですか？

選択肢：

A. 振る舞い駆動開発（Behavior Driven Development: BDD）

B. テストレベル駆動開発（Test Level Driven Development）

C. 機能駆動開発（Function Driven Development）

D. 性能駆動開発（Performance Driven Development）

正解： ✅ A. 振る舞い駆動開発（BDD）

解説：

テストファーストアプローチとは、「テストケースや受け入れ条件を先に定義し、その後に開発を進める」考え方です。

BDDでは、ユーザーの行動（Behavior）をベースに、期待される結果をテストとして先に書くことで、品質を軸に開発を進めます。

具体例：

たとえばECサイトで「ユーザーが商品をカートに追加できること」をシナリオとして、

Given ユーザーが商品ページを開いている   When 「カートに追加」をクリックする   Then カートにその商品が表示される

という形で先にテストを定義します。

✅まとめ

徹底攻略 JSTQB Foundation教科書＆問題集 シラバス2023対応 [ 梅田 弘之 ]

posted with カエレバ

楽天市場

Amazon

「なぜその答えになるのか」を理解すれば、本番試験で迷わず解答できるようになります。

質問1：典型的なテストの目的はどれ？

典型的なテストの目的はどれ？

選択肢：

A. テスト対象内の欠陥を発見し修正する

B. 開発者との効果的なコミュニケーションを維持する

C. 法的要件が満たされていることを確認する

D. テスト対象の品質に対する信頼を構築する

解説：

• A：欠陥を発見するのはテストの目的ですが、修正するのは開発者の仕事。

• B：コミュニケーションは重要ですが、テストの目的ではありません。

• C：法的要件の確認も大切ですが、これは「コンプライアンス評価」であり、一般的なテスト目的とは異なります。

• D：正解！ テストの主要な目的のひとつは「品質に対する信頼を高める」ことです。

✅ 正解：D

質問2：障害者対応とボーナス計算エラーのケース

問題文（要約）：

デザイナーが疲れており、障害者に配慮したUI設計を十分に行わなかった。

開発者はその設計通りに実装したが、時間的プレッシャーから例外処理を入れなかった。

運用後、障害者から苦情があり罰金が課せられた。また、ボーナス計算が時々誤っているが誰も気づいていない。

選択肢：

A. ボーナスの誤計算は、時々発生する欠陥である

B. 障害者対応不足による罰金は「失敗（failure）」である

C. 開発者が時間的プレッシャー下で作業したことが根本原因（root cause）である

D. UI設計にデザイナーのエラーが含まれている

解説：

• A：まだ誰も気づいていないので、「欠陥が検出された」とは言えません。

• B：罰金は「欠陥の結果」ではありますが、ISTQB的には「失敗」とは定義しません。

• C：正解！　開発者が時間的制約下で例外処理を入れられなかったことが根本原因です。

• D：デザイナーが疲れていたとはいえ、意図的なエラーではないため不正確です。

✅ 正解：C

質問3：テストケースを毎回変える理由

テスト条件は同じままですが、テストケースは毎回異なります。

この場合、どのテストの原則が当てはまりますか？

選択肢：

A. テストは劣化する（Tests wear out）

B. 欠陥が存在しないという誤った仮定を避ける（Absence of defects fallacy）

C. 早期テストはコストを削減する（Early testing saves time and money）

D. 欠陥は集中する傾向がある（Defects cluster together）

解説：

テスト条件が同じでも、テストケースを変えるのは、同じ手順では見つからない欠陥を発見するためです。

同じテストを繰り返すと「テストの劣化」が起き、新しいバグを見逃す可能性があるためです。

✅ 正解：A（テストは劣化する）

質問4：どのテストタスクがどのテスト活動に対応するでしょう？

どのテストタスクがどのテスト活動に対応するでしょう？

テストタスク：

1. テスト条件からテストケースを導出する

2. 再利用可能なテストウェアを特定する

3. テストケースをテスト手順にまとめる

4. テストベースとテスト対象を評価する

テスト活動：

A. テスト分析

B. テスト設計

C. テスト実装

D. テスト完了

解答対応：

解説：

• 「テスト条件からテストケースを導出」→設計フェーズ

• 「再利用可能なテストウェアを特定」→完了時にまとめる

• 「テストケースを手順にまとめる」→実装フェーズ

• 「テストベースを評価」→分析フェーズ

✅ 正解：B

質問5：テスト実装の成果物

次のうち、テスト実装（Test Implementation）の結果として作成されるテストウェアはどれですか？

選択肢：

A. テスト完了報告書

B. テスト入力・期待結果を格納したデータベース

C. テスト環境を構築するための要素リスト

D. 実行順に並べたテストケース手順書

E. テストケース

解説：

• A：テスト完了報告書はテスト完了フェーズの成果物。

• B・D：正解！ テスト実装では、テストデータベース（入力値・期待結果）や、実行順に並べた手順書を作成します。

• C：環境構築は「テスト準備」の段階。

• E：テストケースは「設計」フェーズで作成します。

✅ 正解：Aの組み合わせ（BとDが該当）

まとめ

今回のPart #31では、特に「テストプロセスと成果物」に関する出題が中心でした。

ISTQB試験では、単なる暗記ではなく「どの工程で何が作られるか」を理解していることが問われます。

💡 ポイント：ISTQBでは「因果関係の理解」が鍵です。
どの原因（root cause）が、どの結果（defect/failure）につながるかを整理しましょう。

徹底攻略 JSTQB Foundation教科書＆問題集 シラバス2023対応 [ 梅田 弘之 ]

posted with カエレバ

楽天市場

Amazon

出題テーマは「テストプロセス」「構成管理」「欠陥報告」「テスト管理ツール」「テスト自動化の利点」など、試験に頻出する重要ポイントばかりです。

✅ 質問36：テストプロセスで「テスト進捗報告書」が最も活用される活動はどれ？

選択肢：

A. テスト計画（Test Planning）

B. テスト完了（Test Completion）

C. テスト分析（Test Analysis）

D. テスト設計（Test Design）

正解：B. テスト完了（Test Completion）

解説：

「テスト進捗報告書（Test Progress Report）」は、テスト活動の進捗・達成度を関係者に報告するための文書です。

主にテストの実行中および完了時に作成されます。

• テスト計画段階ではまだ実績データがないため、進捗報告書は存在しません。

• 分析や設計の段階も同様です。

• したがって、**最も多く活用されるのは「テスト完了時」**です。

具体例：

たとえば、100件のテストケースのうち80件が実行済み、70件がパス、10件が失敗というような進捗をまとめ、完了報告書に反映します。

✅ 質問37：構成管理がテストを支援する方法のうち、「該当しない」ものはどれ？

選択肢：

A. すべてのリポジトリへのコミットがバージョン管理で一意に識別される

B. テスト環境の構成要素が追跡される

C. すべての要求仕様がテスト計画で明確に参照される

D. すべての特定された欠陥にステータスが割り当てられる

正解：D. すべての特定された欠陥にステータスが割り当てられる

解説：

構成管理（Configuration Management）は、バージョン管理・テスト環境・成果物の整合性維持を目的とします。

一方、「欠陥にステータスを割り当てる」のは**欠陥管理（Defect Management）**の領域です。

具体例：

• 「A」「B」「C」は、環境構成・バージョン追跡・要求との整合など、構成管理の支援対象です。

• 「D」は、欠陥の状態（新規／修正中／再テスト済みなど）を管理する作業であり、構成管理ではなく欠陥管理プロセスで扱われます。

✅ 質問38：欠陥報告書で「最も重要な欠落情報」はどれ？

欠陥レポート内容（例）：

• アプリ名：WebShop

• バージョン：1.2

• タイトル：ログインボタンが動作しない

• 再現手順：①Webサイトを起動 → ②ログインボタンをクリック

• 期待結果：ログインページにリダイレクトされる

• 実際の結果：反応しない

• 重大度：高

• 優先度：緊急

選択肢：

A. テスター名と報告日

B. テスト環境の構成要素とバージョン番号

C. テスト対象の識別情報

D. ステークホルダーへの影響

正解：B. テスト環境の構成要素とバージョン番号

解説：

一見すると欠陥報告書は完璧に見えますが、「どの環境で発生したのか」が書かれていません。

テスト環境の構成（OS、ブラウザ、アプリのバージョンなど）は、再現・修正に不可欠な情報です。

具体例：

「SIT1環境のv1.2で発生」「UAT環境のv1.3では再現せず」など、環境ごとの差異が問題解決に直結します。

したがって、テスト環境情報は最も重要な欠落情報です。

✅ 質問39：テストケース・欠陥・構成を一元管理できるツールカテゴリはどれ？

選択肢：

A. テスト実行・カバレッジツール

B. テスト設計・実装ツール

C. 欠陥管理ツール

D. テスト管理ツール

正解：D. テスト管理ツール

解説：

テスト管理ツール（Test Management Tool）は、以下のような情報を統合的に扱えます。

• テストケースの設計・管理

• テスト実行結果の記録

• 欠陥のトラッキング

• 構成管理との連携

具体例：

• Jira + Xray や TestRail は代表的なテスト管理ツールです。

• これらはテストケースと欠陥、構成を一括で管理でき、チーム全体での品質管理に役立ちます。

✅ 質問40：テスト自動化の最も可能性の高い利点はどれ？

選択肢：

A. テストベースにアクセスせずにテストケースを自動生成できる

B. 客観的評価によるカバレッジの向上

C. 処理能力の向上による実行時間の増加

D. 一貫性と再現性によるヒューマンエラーの防止

正解：D. 一貫性と再現性によるヒューマンエラーの防止

解説：

テスト自動化の最大のメリットは、人間の作業ミスを防げることです。

スクリプトにより同じ手順を何度も再現できるため、結果の一貫性が保たれます。

具体例：

• テストデータがExcelやCSVに固定化されているため、入力ミスが減少。

• SeleniumやPlaywrightなどの自動化ツールで、毎回同じ操作が実行可能。

• 回帰テストを自動化することで、リリース前に効率よく品質確認が可能。

🏁 まとめ：Part #30のポイント

💡 試験対策アドバイス

• **テストプロセス（Chapter 1）とツール支援（Chapter 6）**の理解が重要。

• 「何がどのプロセスに属するか」を明確に区別できるようにしましょう。

• 欠陥報告では「再現性」と「環境情報」を常に意識すること。

• 自動化の利点は「スピード」よりも「品質の安定性」に注目！

徹底攻略 JSTQB Foundation教科書＆問題集 シラバス2023対応 [ 梅田 弘之 ]

posted with カエレバ

楽天市場

Amazon

アジャイル開発・テストピラミッド・テストクアドラント・リスク分析など、試験でもよく出題されるポイントが満載です。

✅ 質問31：イテレーションの工数見積り（アジャイル開発）

問題文：

アジャイル開発で、各イテレーションの開始時にチームは必要な作業量（人日）を見積もります。

次のモデルに基づいて、第5イテレーションの見積もりを求めなさい。

与えられた式：

E(n) = (3 × A(n−1) + A(n−2)) ÷ 4
ここで、
E(n)：n回目のイテレーションの見積もり値
A(n)：n回目の実績値

与えられたデータ（グラフより）

• A(3) = 8

• A(4) = 6

選択肢：

A. 5.0

B. 5.5

C. 6.5

D. 7.0

計算：

E(5) = (3 × A(4) + A(3)) ÷ 4
= (3 × 6 + 8) ÷ 4
= 26 ÷ 4 = 6.5

正解：C. 6.5

ポイント解説：

この問題は数式とグラフを読み取るタイプです。

アジャイル開発における反復ごとの見積もり（ベロシティ）を扱っています。

過去実績（A）を使って、将来の見積もり（E）を予測する「外挿（Extrapolation）」がテーマです。

💡具体例：

スクラム開発で「前回スプリントで8ストーリーポイント、今回6だった」とき、次回の見積りを平均傾向で6.5とする、という考え方に近いです。

✅ 質問32：テストケースの優先度と依存関係

問題文：

7つのテストケース（TC1〜TC7）があり、優先度（1が最も高い）と依存関係が次の図で示されています。

この条件のもとで、6番目に実行されるテストケースはどれでしょう？

選択肢：

A. TC3

B. TC6

C. TC4

D. TC7

考え方：

• 優先度1のテストケース：TC5、TC7

• 優先度2のテストケース：TC3、TC4

• 優先度3のテストケース：TC6

• 依存関係：矢印で示され、「→」の右側は左側の実行が必要。

解説：

1. TC7を実行するにはTC4が必要（依存）

2. TC5を実行するにはTC1、TC2、TC4が必要

3. したがって、まずTC4を実行 → TC7を実行

4. 次にTC1 → TC2 → TC5

5. 残るはTC3とTC6。TC3が優先度2、TC6が3なので、TC3を先に実行。

正解：A. TC3

💡ポイント：

現場でも「依存関係」と「優先度」を同時に考慮してテスト順序を決定します。

この問題は、テストスケジューリングのロジック理解を問う定番問題です。

✅ 質問33：テストピラミッドモデル（Test Pyramid Model）

問題文：

テストピラミッドモデルが示しているのはどれ？

選択肢：

A. テストは異なる優先度を持つ

B. テストは異なる粒度（granularity）を持つ

C. テストは異なるカバレッジ基準を必要とする

D. テストは他のテストに依存する

正解：B. テストは異なる粒度を持つ

解説：

テストピラミッドとは、下層に単体テスト（多数・詳細）、中層にAPIテスト、上層にUIテストを配置したモデルです。

下層ほど数が多く、上層ほど少ない。つまり、テストの粒度が異なります。

💡具体例：

• 単体テスト（Unit）：個々の関数を細かくテスト

• APIテスト：モジュール間の通信を確認

• UIテスト：全体の動作をエンドツーエンドで確認

✅ 質問34：テストクアドラント（Agile Testing Quadrants）とテストレベル・タイプの関係

問題文：

テストクアドラント、テストレベル、テストタイプの関係について正しい説明はどれ？

選択肢：

A. テストクアドラントはSDLC内での位置を定義する

B. テストクアドラントはテストタイプの粒度を示す

C. テストクアドラントはテストタイプをテストレベルに割り当てる

D. テストクアドラントは、ステークホルダー別にテストレベルとテストタイプをグループ化する

正解：D. テストクアドラントはステークホルダー別にテストレベルとテストタイプをグループ化する

解説：

テストクアドラントは、アジャイルにおけるテストの「目的」と「関係者」を分類するフレームワーク。

• Q1・Q2は「開発者支援」テスト（技術寄り）

• Q3・Q4は「ビジネス価値」重視のテスト（顧客寄り）

💡具体例：

• Q1：ユニットテスト（技術的、開発者向け）

• Q2：機能テスト（ビジネスロジック確認）

• Q3：ユーザー受け入れテスト（UAT）

• Q4：ユーザーエクスペリエンス、性能テストなど

✅ 質問35：プロダクトリスク分析とテストの徹底度・範囲

問題文：

プロダクトリスク分析が、テストの徹底度（thoroughness）や範囲（scope）に影響する例として正しいものはどれ？

選択肢：

A. 継続的なリスク監視で新たなリスクを早期に発見できる

B. リスク特定によりリスク軽減策を実施できる

C. 評価されたリスクレベルによってテストの厳密さ（rigor）を決定できる

D. リスク分析でカバレッジ項目を導き出せる

正解：C. 評価されたリスクレベルによってテストの厳密さを決定できる

解説：

リスクが高ければテストをより厳密に行う必要があります。

これが「リスクベースドテスティング（RBT）」の考え方です。

💡具体例：

• 銀行システムなど「高リスク領域」→ 詳細なテスト、複数回実施

• 低リスク機能（UI色変更など）→ 簡易的な確認で十分

🧭 まとめ

これらの問題は、ISTQB CTFL試験の Chapter 4「テスト設計技法」 や Chapter 5「テスト管理」 の重要ポイントを総復習できます。

特にアジャイル関連（ピラミッド、クアドラント）は近年の出題傾向として増加しています。

徹底攻略 JSTQB Foundation教科書＆問題集 シラバス2023対応 [ 梅田 弘之 ]

posted with カエレバ

楽天市場

Amazon

「テスト技法」や「チェックリストテストのカバレッジ」「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. 通常ユーザーは1〜3階にアクセスできる

2. 4階は特別ユーザーのみアクセス可能

3. 特別ユーザーは通常ユーザーのアクセス権をすべて持つ

選択肢：

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）**に記述されるべき内容です。

🎯まとめ

これらの問題はISTQB Foundation試験の中でも試験頻出トピックであり、

それぞれの用語と適用シーンを具体的に理解しておくことが合格への近道です。

徹底攻略 JSTQB Foundation教科書＆問題集 シラバス2023対応 [ 梅田 弘之 ]

posted with カエレバ

楽天市場

Amazon

今回の動画では、試験によく出る「境界値分析」「決定表」「状態遷移テスト」「ブランチテスト」「ホワイトボックスとブラックボックスの関係」など、テスト設計技法の核心を押さえた5問が解説されています。

質問1：二値境界値分析（Two-Value Boundary Value Analysis）

シナリオ：

開発者は以下のビジネスルールを実装するように依頼されました。

入力値は整数値。

値が100以下または200以上の場合、「value is incorrect」と出力。

それ以外（101〜199）の場合、「value is OK」と出力。

このとき、「二値境界値分析（Two-Value Boundary Value Analysis）」を使ってテスト設計を行う場合、

最も高いカバレッジを達成するテストデータの組み合わせはどれでしょうか？

選択肢

A. 100, 150, 200, 20

B. 99, 200, 201

C. 98, 99, 100, 101

D. 101, 150, 199, 200 ✅

解説

この仕様では、有効な値の範囲は「101〜199」。

よって、無効値は「100以下」と「200以上」です。

境界値：

• 下側の境界：100, 101

• 上側の境界：199, 200

二値境界値分析では、各境界の境界値とその隣接値をテストします。

したがって理想的なテストデータは 100, 101, 199, 200 です。

選択肢Dのセット「101, 150, 199, 200」は、

この中の 3つの境界値（101, 199, 200） を網羅しており、

最も高いカバレッジ（約75%）を達成します。

👉 正解：D

補足例：

もし「三値境界値分析（Three-Value）」を使うなら、各境界にもう1点追加して

「99, 100, 101, 198, 199, 200, 201」などをテストする形になります。

質問2：決定表テスト（Decision Table Testing）

シナリオ：

運転免許試験結果を分析するシステムのテスト設計を行っています。

次の決定表に基づいてテストデータを作成したところ、

「矛盾するルール（Contradictory Rules）」が存在することがわかりました。

どのテストデータがその矛盾を示すでしょうか？

決定表ルール

選択肢

A. C1=T, C2=T, C3=F

B. C1=T, C2=F, C3=T

C. C1=T, C2=T, C3=T

D. C1=F, C2=F, C3=F ✅

解説

ルールR2とR3の両方が「C2=F, C3=F」で成立しており、

出力が異なるため 矛盾（Contradiction） が発生しています。

👉 正解：D

具体例：

たとえば「学科も実技も不合格」の場合、

「再試験の案内」と「追加講習の案内」という相反する指示が出てしまうのが矛盾です。

質問3：状態遷移テスト（State Transition Testing）

シナリオ：

宿泊予約システムの状態遷移は次のようになっています。

開始 → 部屋リクエスト → 「リクエスト中」状態 →

① 空室あり → 「確認済み」→ 支払い → 終了

② 空室なし → 「ウェイトリスト」→

　a) キャンセル → 終了

　b) 空室発生 → 「確認済み」→ 支払い → 終了

このとき、100%有効遷移カバレッジを達成するために必要な最小テストケース数は？

選択肢

A. 3 ✅

B. 4

C. 2

D. 5

解説

すべての有効遷移（Valid Transition）を網羅するためには、

以下の3つのシナリオが必要です。

1. 空室あり → 直接予約・支払い・終了

2. 空室なし → ウェイトリスト → キャンセル・終了

3. 空室なし → ウェイトリスト → 空室発生 → 確認・支払い・終了

👉 正解：A

質問4：ブランチテスト（Branch Testing）

シナリオ：

次のコントロールフローグラフに対してブランチテストを適用します。

このとき、**テストすべきカバレッジ項目（branches）**は何個あるでしょうか？

選択肢

A. 6

B. 7

C. 8 ✅

D. 9

解説

ブランチテストでは、分岐（if/elseなど）ごとの経路をテスト対象とします。

フローチャート上で「分岐の線（矢印）」を数えると、合計で8本あります。

👉 正解：C（8本）

具体例：

もしコード中に「if文が3つ」あるなら、通常はそれぞれにTrue/Falseの2通りがあるため、

最大で6分岐（＝6ブランチ）を確認します。

質問5：ホワイトボックスとブラックボックスの関係

問題：

「ホワイトボックステストはブラックボックステストの支援としてどのように役立つか？」

選択肢

A. ホワイトボックスのカバレッジ指標は、ブラックボックステストのコードカバレッジを評価するのに役立つ ✅

B. ホワイトボックス分析は、到達不能コードを特定できる

C. ブランチテストはブラックボックステスト技法を包含する

D. ホワイトボックステストはブラックボックス技法のテスト項目を提供する

解説

Aが正解です。

ブラックボックステストでは主に外部仕様を基準にテストしますが、

ホワイトボックスカバレッジを確認することで、

「どのくらいコードが実際にテストされているか」を定量的に評価できます。

つまり、ホワイトボックステストはブラックボックステストを裏側から補完します。

👉 正解：A

まとめ

💡 試験対策のポイント

• 境界値分析：境界＋隣接値を意識（100/101、199/200など）

• 決定表：複数ルールが同時に成立していないかチェック

• 状態遷移：すべての有効経路（Valid Transition）を洗い出す

• ブランチテスト：分岐ごとのTrue/False経路を確認

• ホワイト×ブラックの関係：仕様テスト＋コード網羅の両輪で品質向上

徹底攻略 JSTQB Foundation教科書＆問題集 シラバス2023対応 [ 梅田 弘之 ]

posted with カエレバ

楽天市場

Amazon

「アジャイルでの早期フィードバック」「レビュー技法の違い」「成功するレビューの要因」

「ブラックボックスと経験ベースの違い」「同値分割の考え方」

といった定番テーマがこの動画でカバーされています。

それぞれの問題を、実例を交えて詳しく解説していきましょう。

✅ 質問1：早期かつ頻繁なステークホルダーフィードバックの利点は？

問題文：

次のうち、早期かつ頻繁なステークホルダーからのフィードバックの利点として最も適切なものはどれでしょう？

選択肢：

1. 要件の変更が早期に理解され、実装される

2. ビジネス側がユーザー要件を理解できる

3. プロダクトオーナーがいつでも要件を変更できる

4. エンドユーザーに未実装の要件を伝えられる

正解： ① 要件の変更が早期に理解され、実装される

💡解説：

アジャイル開発の特徴は「ステークホルダーとの継続的な対話」です。

早い段階でフィードバックを受けることで、要求のズレを早期に発見・修正できます。

例：

新しいECサイトを開発中に、ユーザーが「支払い方法をもっと増やしたい」と早めに指摘してくれたら、リリース前に修正できる＝手戻りが少ない。

✅ 質問2：レビュータイプとその特徴の対応

与えられたレビュータイプ：

• Technical Review（技術レビュー）

• Informal Review（インフォーマルレビュー）

• Inspection（インスペクション）

• Walkthrough（ウォークスルー）

主な記述：

• A：合意形成や新しいアイデア創出、著者の改善意欲向上を目的とする

• B：教育・合意形成・アイデア出し・欠陥検出などを目的とする

• C：欠陥検出を主目的とし、メトリクス収集を行う

• D：欠陥検出が目的だが、正式な文書出力は伴わない

【選択肢（Options）】

A)　1–A, 2–C, 3–D, 4–B

B)　1–A, 2–D, 3–C, 4–B

C)　1–C, 2–A, 3–B, 4–D

D)　1–C, 2–D, 3–A, 4–B

正しい対応：

• 1. Technical Review → A

• 2. Informal Review → D

• 3. Inspection → C

• 4. Walkthrough → B

正解： B（1A, 2D, 3C, 4B）

💡解説：

例：

コードレビュー会議を行う場合、チェックリストに基づいて欠陥数を集計するなら「インスペクション」。逆に、開発者同士で軽く確認するなら「インフォーマルレビュー」。

✅ 質問3：成功するレビューの要因は？

問題文：

次のうち、レビューを成功させる要因として正しいものはどれ？

選択肢：

1. 管理職がレビュアーとして参加する

2. 大きな成果物を小さく分割する

3. レビュアーの能力評価を目的にする

4. 1回のレビューで1文書すべてを対象にする

正解： ② 大きな成果物を小さく分割する

💡解説：

1回のレビューで膨大な文書を扱うと、集中力が切れ欠陥を見逃しがちです。

章ごとや機能単位など、小さく分割してレビューを行うのが成功のコツです。

例：

仕様書100ページを1日でレビュー → 非現実的

10ページずつ分割してレビュー → 効果的かつ持続的

✅ 質問4：ブラックボックスと経験ベースの違い

問題文：

ブラックボックステスト技法と経験ベーステスト技法の主な違いはどれ？

選択肢：

1. テストオブジェクト

2. テストレベル

3. テストベース

4. 使用するSDLCフェーズ

正解： ③ テストベース

💡解説：

• ブラックボックス技法：要件や仕様書といった「明確なテストベース」に基づいてテスト設計する

• 経験ベース技法：テストベースが明確でない場合に、テスターの経験や直感で設計する

例：

仕様書がしっかりある → 同値分割・境界値分析（ブラックボックス）

仕様書が曖昧 → 探索的テスト（経験ベース）

✅ 質問5：同値分割（Equivalence Partitioning）の応用問題

問題文：

PINコードバリデータをテストする。PINは「4桁の数字で、少なくとも2桁が異なる」場合に有効とする。

すべての同値分割をカバーする入力データの組み合わせはどれ？

【選択肢（Options）】

A)　112, 1111, 1234, 123456

B)　111, 1111, 1234

C)　12, 1122, 1234

D)　1111, 1112, 12345

考え方：

同値分割の整理

正しい入力データセット：

A) 112（3桁）／1111（同じ数字）／1234（すべて異なる）／123456（6桁）
→ すべての同値分割をカバー

正解： A

💡解説：

テストケース設計では、単に「4桁かどうか」だけでなく、値のバリエーション条件も考慮することが重要です。

この考え方は、実務での入力フォームテストにもそのまま応用できます。

🧠 まとめ：Part #26で学ぶべきポイント

徹底攻略 JSTQB Foundation教科書＆問題集 シラバス2023対応 [ 梅田 弘之 ]

posted with カエレバ

楽天市場

Amazon

特に「Shift Leftアプローチ」や「アジャイルのレトロスペクティブ」など、実務でも役立つ内容が多く含まれています。

質問1：Shift Leftアプローチの正しい説明はどれ？

選択肢：

A. 開発者が同意した場合、テストプロセスの左側にある手動作業をすべて自動化する。

B. 品質コストを削減するために、テスト活動をソフトウェア開発ライフサイクルの初期段階へ移動する。

C. テスターが空き時間に回帰テストの自動化を行う。

D. テスターが早期に作業できるようトレーニングを受ける。

正解：B

解説：

Shift Left（シフトレフト）とは、「テスト活動をできるだけ早い段階（左側）に移動させる」考え方です。

これにより、欠陥を早期に検出でき、修正コストを大幅に削減できます。

例えば、ウォーターフォール型開発では、テストは開発完了後に実施されます。

しかし、Shift Leftでは要件定義や設計段階からテスターを関与させ、レビューや静的解析を行うことで、手戻りを防ぎます。

💡 例：

• コードレビューや設計レビューを早期に実施

• 要件レビューで曖昧な部分を明確化

• 自動テストの仕組みを開発初期から組み込む

質問2：レトロスペクティブ（振り返り）の結果として「最も起こりにくい」ものはどれ？

選択肢：

A. 開発プロセスの改善により、将来のテスト対象の品質が向上する。

B. テスト環境の自動化によってテスト効率が向上する。

C. エンドユーザーの開発・テストプロセスに対する理解が深まる。

D. 開発者からのフィードバックに基づき、自動テストスクリプトが改善される。

正解：C

解説：

アジャイルにおけるレトロスペクティブは、チームの内部改善を目的とするミーティングです。

そのため、外部のエンドユーザーの理解が深まることは直接的な成果ではありません。

💡 ポイント：

• A・B・Dは「チーム内部の改善」に関する内容 → 実際によく起こる

• Cは「エンドユーザー理解の向上」→ 関係性が薄く、最も起こりにくい

質問3：「バリデーション」に焦点を当て、テスター以外が実施するテストレベルはどれ？

選択肢：

A. コンポーネントテスト

B. コンポーネント統合テスト

C. システム統合テスト

D. 受け入れテスト

正解：D

解説：

「バリデーション」とは、製品がユーザーの期待どおりに動作するか確認する活動です。

受け入れテストは通常、エンドユーザーやビジネス担当者が行うため、テスター以外が担当します。

💡 例：

• ECサイトの最終テストで、顧客担当者が「購入フローが期待通りか」を確認

• 医療機器ソフトで、専門医が機能を確認する受け入れテストを実施

質問4：ナビゲーションシステムの更新後、どのテストを行うべきか？

シナリオ：

ナビゲーションソフトが「一方通行の逆走ルートを案内する」不具合を修正した。

選択肢：

A. 確認テストのみ

B. 確認テスト → 回帰テスト

C. 回帰テストのみ

D. 回帰テスト → 確認テスト

正解：B

解説：

このケースでは、不具合修正を行った後に

1️⃣ まず修正が正しく反映されたか確認（確認テスト / Re-testing）

2️⃣ 修正によって他の機能が影響を受けていないか検証（回帰テスト / Regression Testing）

という順番でテストします。

💡 例：

• 「ルート案内修正」が正しいか確認 → 確認テスト

• 他の経路案内（高速道路・迂回路など）が影響を受けていないか確認 → 回帰テスト

質問5：静的テストで検出できる欠陥はどれ？

例として挙げられた欠陥：

1. 設計仕様書の2箇所が矛盾している。

2. 応答時間が長く、ユーザーが不満を感じる。

3. コード内の特定のパスに到達できない。

4. 宣言された変数が一度も使用されていない。

5. レポート出力時のメモリ使用量が多すぎる。

正解：1・3・4

解説：

静的テスト（Static Testing）は、プログラムを実行せずに欠陥を発見する手法です。

主にレビューや静的解析で行われ、ドキュメントやコードの構造的な問題を特定します。

💡 静的テストで発見できる例：

• 設計書や仕様書の矛盾（例：画面設計と要件定義の不一致）

• 未使用の変数・到達不能コード

• コーディング規約違反

一方で、応答速度やメモリ使用量の問題（2, 5）は、実行時の動作を確認する動的テストでしか発見できません。

まとめ：今回のポイント

💬 まとめのひとこと

ISTQB試験では、「どのテストレベルで」「どのテストタイプを」「どの目的で実施するか」を理解しているかが重要です。

実務でも「Shift Left」や「レトロスペクティブ」などの考え方は、チームの品質向上に直結します。

理論と実践を結びつけて、知識を定着させましょう。

徹底攻略 JSTQB Foundation教科書＆問題集 シラバス2023対応 [ 梅田 弘之 ]

posted with カエレバ

楽天市場

Amazon

1. テストロール（Test Roles）の正しい理解

2. ホールチームアプローチ（Whole Team Approach）の利点

3. テストの独立性（Independence of Testing）

4. すべてのSDLCに共通する良いテストプラクティス

5. テストファーストアプローチ（Test-First Approach）

それぞれの問題の背景や考え方を、具体例を交えて解説していきます。

❓質問1：テストロールに関する正しい記述はどれ？

質問内容

次のうち、異なるテストロールに関する記述として最も正しいのはどれか？

選択肢

A. アジャイル開発では、テスト管理はチーム全体の責任だが、実際のテストはチーム外の個人が担当する。

B. テスティングロールはモニタリングを担当し、テストマネジメントロールは計画と完了を担当する。

C. アジャイル開発において、複数チームにまたがるテスト管理活動はチーム外のテストマネージャーが担当し、一部のタスクはチーム内でも行う。

D. テストマネージャーは分析と設計を担当し、テスターは実装と実行を担当する。

正解：C

解説：

アジャイル開発では、「品質はチーム全体の責任」です。

ただし、複数チームを横断するテスト活動（リリース全体のテスト計画や統合など）は、チーム外のテストマネージャーがまとめることもあります。

📘 例：

Woven by ToyotaやSpotifyのように複数スクラムチームが同時に開発している場合、各チームの中ではQA担当者が自律的に動き、全体の品質を横断的に管理する役割を“テストマネージャー”が担います。

❓質問2：ホールチームアプローチの利点はどれ？

質問内容

ホールチームアプローチ（Whole Team Approach）の利点として正しいのはどれ？

選択肢

A. テスターのいないチームを作れる

B. チームの協働が改善する

C. 専門職メンバーを増やす

D. チーム規模を大きくできる

正解：B

解説：

ホールチームアプローチとは、「開発者・テスター・プロダクトオーナーが一体となって品質を作り上げる」考え方です。

この手法の最大の利点は **「チーム全体の連携が深まり、コミュニケーションが活発になる」**ことです。

📘 例：

スプリント計画で、開発者がテストケース設計に参加する、あるいはQAがユーザーストーリーの受け入れ条件をレビューするなど、役割の垣根を超えて協働するのが理想的なチームです。

❓質問3：テストの独立性に関する正しい記述はどれ？

質問内容

次のうち、テストの独立性（Independence of Testing）について正しいものはどれか？

選択肢：

A.　独立したテスターは、開発者とは異なる技術的視点を持つため欠陥を発見しやすいが、

その独立性により開発者との間に対立的な関係が生じる可能性がある。

B.　開発者は自分のコードに慣れているため欠陥をあまり見つけられないが、

テスターも開発者と同じ技術的背景を持つため、同じ欠陥しか発見できない。

C.　独立したテストは、開発チームの外部、理想的には組織外のテスターによって行う必要があるが、

この場合、テスターはアプリケーション領域を理解するのが難しくなる。

D.　開発チーム外のテスターはチーム内のテスターよりも独立性が高いが、

チーム内のテスターは製品リリースの遅延の責任を負わされる傾向がある。

正解：A

独立したテスターは、開発者とは異なる技術的視点を持つため、欠陥を発見しやすいが、開発者との間で対立的な関係になる可能性がある。

解説：

テストの独立性とは、「開発者以外の第三者がテストを行うことで、客観的な品質評価を可能にする」ことです。

ただし、独立しすぎると“対立的な雰囲気”になりかねません。大切なのは、独立性と協調性のバランスです。

📘 例：

• ✅ 良い独立性：別チームのQAがコードを客観的にレビューする

• ❌ 悪い独立性：テスターと開発者が責任を押し付け合う関係になる

❓質問4：すべてのSDLCに共通する良いテストプラクティスはどれ？

質問内容

どのソフトウェア開発ライフサイクル（SDLC）にも共通する良いテストプラクティスはどれ？

選択肢：

A.　各テストレベルには、対応する開発レベルが存在する。

B.　各テスト目的には、対応する開発目的が存在する。

C.　すべてのソフトウェアテスト活動には、対応するユーザー活動が存在する。

D.　すべてのソフトウェア開発活動には、対応するテスト活動が存在する。

正解：D

各ソフトウェア開発活動には、対応するテスト活動がある。

解説：

テストは開発の後ではなく、並行して行うのが理想的です。

要件定義にはレビュー、設計にはテスト設計、コーディングには単体テスト、統合にはシステムテスト…というように、「すべての開発工程にテストが対応」しています。

📘 例：

Vモデルでは、左側の開発工程（要件・設計・実装）と、右側のテスト工程（受入・システム・統合・単体）が対応しています。これが良いテストプラクティスの典型です。

❓質問5：テストファーストアプローチに該当するのはどれ？

質問内容

次のうち、テストファーストアプローチ（Test-First Approach）に該当するのはどれ？

選択肢

A. コンポーネントテスト駆動開発

B. 統合テスト駆動開発

C. システムテスト駆動開発

D. 受入テスト駆動開発

正解：D（ATDD: Acceptance Test Driven Development）

解説：

テストファーストアプローチとは、「テストを先に作り、その基準を満たすように開発する」手法です。

中でも「ATDD（受入テスト駆動開発）」は、ユーザーストーリーの受け入れ基準を先に定義し、開発がそれを満たすよう進めます。

📘 例：

ユーザーストーリー：「ユーザーがログインに成功したら、ダッシュボードに遷移する」

→ 最初に「ログイン成功時にダッシュボード画面が表示される」という受入テストを書き、それをパスさせるコードを実装するのがATDDです。

🧭まとめ：アジャイル時代のISTQB知識を“実務で活かす”

このPart #24では、ISTQBシラバスの基礎項目をアジャイルの観点から整理しました。

アジャイル開発におけるISTQBの知識は、単なる理論ではなく「チームで品質を作る」ための実践指針になります。

この理解を深めることで、試験合格はもちろん、現場でのテスト設計力・品質意識も確実に高まります。

徹底攻略 JSTQB Foundation教科書＆問題集 シラバス2023対応 [ 梅田 弘之 ]

posted with カエレバ

楽天市場

Amazon