第 3 章：静的テスト｜JSTQB FL、1回落ちた私がガチで作った問題集
JSTQB FL(Foundation Level)、1回落ちました。
わたくし、テス子と申します。
正直、「そこまで難しくないだろう」と思っていたんですが、見事に不合格（笑）。
私はJSTQB FLレベルでよく使われている問題集アプリを解くだけでは全く歯が立ちませんでした。。
でも、そのおかげで
「どこで間違えたのか？」
「どうすれば合格できるのか？」
を徹底的に分析することができ、2回目で無事合格！
この問題集は、過去問がないこのテストで「どうやって勉強を進めればいいのか？」 を押さえながら、本気で合格を目指せるように作ったものです。
JSTQB FLは暗記だけじゃダメ！
JSTQB FLは、単なる暗記ではなく、
“シラバスの内容を正しく理解しているか” が問われる試験です。
そこで、この問題集では、
✅ 1回目の試験で苦戦した自分が、2回目の試験で確実に点を取るために考えた対策を詰め込みました。
具体的には…
各章に設けられている「学習の目的」に沿って、シラバスを理解する
学習の目的に沿って、シラバスから自分で問題を作成する
正解だけでなく、誤答の選択肢も確認し、なぜ間違いなのかを理解する
✅ 答えの内容だけでなく、その他の選択肢も確認し、該当の選択肢がなぜ誤りなのかを認識することがとても大切です。
本番では、似たような問題がひねりを加えられて出題されることが多いので、「なぜ間違いなのか」を理解しておくことで応用力が身につきます！
この問題集を活用して、本番で後悔しないように、しっかり準備しましょう！
こんな人におすすめ！
✅ シラバスを読んでいるだけでは、眠くなってしまう…！
✅ 過去問がないのに、どうやって勉強すればいいのかわからない！
✅ とにかく問題をたくさん解いて、効率的・実践的に学びたい！
📌 JSTQB FL 第3章「静的テスト」 要約
🔹 3.1 静的テストの基本
📖 3.1.1 静的テストで確認できるプロダクトの種類
静的テストとは、ソフトウェアを実行せずに行うテストです。📄🔍
レビューや静的解析ツールを使用して、さまざまな作業成果物を確認します。
✅ 静的テストの対象となる成果物：
要件仕様書
設計書
ソースコード
テスト計画書
テストケース
プロジェクトドキュメント
契約書など
ポイント：
「読むだけで理解できるもの」が静的テストの対象です。
実行ファイルなど、人間が直接確認できないものは対象外です。
📖 3.1.2 静的テストの価値
静的テストは、ソフトウェア開発の初期段階で実施でき、欠陥を早期に発見できます。⏰💡
欠陥を早期に見つけることで、後から修正するよりもコストを大幅に削減できます。💸✨
✅ 静的テストのメリット：
早期の欠陥検出 → リリース後に見つけるよりも安価に修正可能。
品質向上 → 曖昧な要件や設計ミスを早い段階で見つけられる。
ステークホルダー間の認識合わせ → 要件や仕様の誤解を防止できる。
静的解析ツールの活用 → コーディングミスや到達不能コードを自動で発見できる。⚙️💻
📖 3.1.3 静的テストと動的テストの比較
静的テストはソフトウェアを実行せずに、ドキュメントやコードを直接確認して欠陥を見つけます。
動的テストはソフトウェアを実行し、実際の動作を確認しながらエラーや不具合を発見します。
✅ 静的テストの特徴：
ドキュメントやコードを直接確認。
仕様の矛盾、設計ミス、コーディングルール違反などを発見できる。
ソフトウェアを実行できない段階でも実施可能。
✅ 動的テストの特徴：
ソフトウェアを実行して動作を確認。
実行時のエラー、パフォーマンスの問題などを発見できる。
完成したソフトウェアが必要。
ポイント：
静的テストと動的テストは相互補完的であり、両方を組み合わせることで、より効果的な品質保証が可能になります。🚀✨
🔹 3.2 レビューのプロセス
📖 3.2.1 早期かつ頻繁なステークホルダーからのフィードバックの利点
**ステークホルダー（関係者）**からの早期かつ頻繁なフィードバックは、ソフトウェアの品質向上に欠かせません。👥💬
開発の初期段階で問題を見つけることで、後戻り作業やコストの増加を防ぐことができます。💸🚫
✅ メリット：
品質の向上 → 要件の誤解や設計ミスを早く発見。
リスクの軽減 → 後半での大きな問題を防止。
コミュニケーションの改善 → ステークホルダー間の認識のズレを防ぐ。
📖 3.2.2 レビュープロセスの活動
レビューは、作業成果物の品質を向上させるための重要な活動です。🔍📄
ISO/IEC 20246 標準に基づくレビュープロセスには以下のステップがあります：
1️⃣ 計画 → レビューの目的、範囲、スケジュールを決定。
2️⃣ レビュー立ち上げ → 参加者に役割を割り当て、必要な資料を配布。
3️⃣ 個々人のレビュー → 各レビューアが作業成果物を確認し、欠陥を洗い出す。
4️⃣ 共有と分析 → 発見した欠陥をチームで共有し、改善策を議論。
5️⃣ 修正と報告 → 欠陥を修正し、レビューの結果をレポートする。
ポイント：
効率的なレビューには、事前準備と計画が不可欠です。📅📝
作業成果物を小さな単位に分けると、レビューの集中力を維持できます。💡
📖 3.2.3 レビューでの役割と責務
レビューにはさまざまな役割があります。それぞれが重要な責務を担っています。👥
マネージャー → レビュー計画の立案とリソースの確保。
作成者 → レビュー対象のドキュメントやコードを作成した人。
モデレーター → レビュー会議の進行役（中立的な立場で議論を促進）。
書記 → レビュー中の意見や発見した欠陥を記録する。
レビューア → 作業成果物を確認し、欠陥や改善点を指摘する。
レビューリーダー → レビュー全体の責任を持つ人（誰が参加するか、スケジュール調整など）。
ポイント：
モデレーターは議論が偏らないように中立性を保つことが重要です。🗣
書記はすべての意見や欠陥を正確に記録する役割を担います。✍️
📖 3.2.4 レビュー種別の比較と対比
レビューには、形式度の異なるいくつかの種類があります。それぞれの特徴を理解して適切なものを選びましょう。
非形式的レビュー → フォーマルな手順はなく、気軽なフィードバックを目的とします。
ウォークスルー → 作成者が主導して行うレビュー。意見交換や理解促進が目的です。
テクニカルレビュー → 技術的な観点で行うレビュー。専門家が参加し、技術的な問題を特定します。
インスペクション → 最も形式的なレビューで、厳密な手順に従います。不正を最大限発見することが目的です。
ポイント：
ドキュメントの重要性やプロジェクトの規模に応じて、適切なレビュー種別を選びましょう。
インスペクションは重要なドキュメントやコードのレビューに適しています。🔎
📖 3.2.5 レビューの成功要因
レビューを成功させるためには、いくつかの重要なポイントがあります。
✅ 成功要因：
明確な目的設定 → 何を達成したいのかを明確にする。🎯
適切なレビュー形式を選択 → 成果物や目的に応じて最適な形式を選ぶ。⚖️
十分な準備時間の確保 → レビューアが事前に準備できるようにする。📅
ステークホルダーへのフィードバック → 発見した問題点や改善点を共有する。🔄
マネジメントのサポート → 上層部の理解と支援が重要。💼
適切なトレーニングの実施 → 参加者に役割と目的を理解してもらう。📚
ポイント：
レビューの目的を忘れず、単なる欠陥探しではなく品質向上を目指しましょう。🚀✨
✨ まとめ - 静的テストの重要性 ✨
✅ 静的テストは、ソフトウェアを実行せずに問題を発見できる強力な手法です。
✅ レビューは静的テストの中心的な活動であり、品質向上に直結します。
✅ 早期フィードバックと適切なプロセスによって、コスト削減と品質向上を実現できます。
✅ 静的テストと動的テストを組み合わせて、より強固な品質保証を目指しましょう！🚀📌 JSTQBの試験では、これらの静的テストの基本と実践が問われます！
静的テストはソフトウェア品質を高めるための強力な武器です💡✅
では、さっそく第3章「ソフトウェア開発ライフサイクル全体を通 してのテスト」の問題に挑戦してみましょう！
第3章のみで全 40問
参照シラバス
ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 Version 2023V4.0.J02
3.1 静的テストの基本
FL-3.1.1 （K1）さまざまな静的テスト技法によって確認できるプロダクトの種類を認識する。
問題 1: 静的テストで確認可能な作業成果物
静的テストで確認できる作業成果物として最も適切なものはどれか？
A) 要件仕様書
B) 実行中のアプリケーション
C) データベースの運用ログ
D) ネットワークトラフィック
解説:
静的テストは、実行せずに作業成果物を確認する技法であり、要件仕様書や設計書、ソースコードなどが対象となる（A）。B、C、D は動的テストで確認する対象物であり、静的テストには適さない。
正解: A
問題 2: 静的解析ツールで解析できる成果物
静的解析ツールで確認できる作業成果物として最も適切なものはどれか？
A) プロジェクトの進捗レポート
B) ソースコード
C) テスト実行結果
D) ユーザーインターフェースのスクリーンショット
解説:
静的解析ツールは、ソースコード（B）の構文や構造を分析して潜在的な欠陥を検出するために使用される。A、C、D は静的解析ツールで直接分析することはできない。
正解: B
問題 3: レビュー対象として適切なドキュメント
次のうち、レビュー対象として最も適切なドキュメントはどれか？
A) 要件仕様書
B) アプリケーションの実行ログ
C) ネットワーク接続状況のスナップショット
D) システムの実行中スクリーン
解説:
レビューは、ドキュメントの品質や内容を確認する静的テスト技法であり、要件仕様書（A）や設計書、テストケースなどが対象となる。B、C、D は動的な情報であり、レビューの対象には適さない。
正解: A
問題 4: 静的テストが適さない作業成果物
静的テストの対象として最も適切でないものはどれか？
A) ソースコード
B) 実行可能バイナリファイル（法的制約あり）
C) テスト計画書
D) プロダクトバックログアイテム
解説:
静的テストは、ソースコードやドキュメント（A、C、D）など、実行せずに確認できる成果物を対象とする。実行可能バイナリファイル（B）は静的解析が困難であり、特に法的制約がある場合は解析できない。
正解: B
問題 5: 静的解析ツールが必要な成果物の特徴
静的解析ツールで解析可能な作業成果物の特徴として最も適切なものはどれか？
A) 人間が自由に解釈できる形式で記述されている
B) 正式な構文や文法に基づいて記述されている
C) 実行中の挙動を記録したファイルである
D) 手書きのメモやイラストを含む非構造化データ
解説:
静的解析ツールは、構文や文法に従ったソースコードやモデル（B）を対象に分析を行う。A（自由記述）やD（非構造データ）は解析できず、C（実行中の挙動記録）は動的解析の対象である。
正解: B
ここから先は
¥ 200
PayPayで支払うと抽選でお得この記事が気に入ったらチップで応援してみませんか？