Foundation Level（FL）模擬試験 セットDの問題と解説

1. A　静的解析 → レビュー → 作業成果物の修正
2. B　テスト設計 → テスト実行 → 欠陥レポートの作成
3. C　故障の再現 → 診断（根本原因の発見） → 原因の修正
4. D　確認テスト → リグレッションテスト → 欠陥レポートのクローズ

1. A　テスト結果はQCでの欠陥修正に使われるが、QAのプロセス改善には使われない
2. B　QAはプロダクト指向の是正アプローチであり、主にテストチームが責任を持つ
3. C　テストはQCの一形式であり、QCはプロダクト指向の是正アプローチである
4. D　テストはQAの主要な形式であり、QAはプロセス指向の予防的アプローチである

1. A　テストの弱化
2. B　「欠陥ゼロ」の落とし穴
3. C　全数テストは不可能
4. D　欠陥の偏在

1. A　テスト実装
2. B　テスト分析
3. C　テストのモニタリングとコントロール
4. D　テスト設計

1. A　モニタリング：テストウェアを保管し、ハンドオーバーする／コントロール：テスト環境を合意した状態でシャットダウンする
2. B　モニタリング：テストの目的を達成するために必要な行動をとる／コントロール：テスト活動を継続的にチェックし、進捗を計画と比較する
3. C　モニタリング：テスト目的とテストアプローチを定義する／コントロール：目的を達成するためのスケジュールと予算を決める
4. D　モニタリング：テスト活動を継続的にチェックし、進捗を計画と比較する／コントロール：テストの目的達成に必要な行動をとる

1. A　テストプロシジャー、自動テストスクリプト、テストスイート、テストデータ
2. B　テストログと、テスト実行中の故障に基づく欠陥レポート
3. C　優先順位を付けたテスト条件と、テストベース内の欠陥の欠陥レポート
4. D　テスト進捗レポートと、コントロールのための指示書

1. A　テスト計画、テストのモニタリングとコントロール、テスト完了
2. B　テスト設計、テスト実行、テスト完了
3. C　テスト分析、テスト設計、テスト実装、テスト実行
4. D　テスト分析、テストのモニタリングとコントロール、テスト実装、テスト完了

1. A　作成者のチーム外だが同じ組織内のテスト担当者
2. B　作業成果物の作成者本人
3. C　作成者と同じチームの仲間
4. D　組織外のテスト担当者

1. A　各イテレーションでは動的テストを行い、静的テストは最初のイテレーションでまとめて実施する
2. B　各イテレーションで、静的テストと動的テストの両方がすべてのテストレベルで行われる可能性がある
3. C　テストレベルはイテレーションごとに1つに決め、コンポーネントテストから順に進める
4. D　インクリメントの提供頻度が高いため、リグレッションテストは範囲を絞り込んで最小限に抑える

1. A　手動テストを自動テストに置き換えることを主な目的とした、テストツールとフレームワークの総称
2. B　テスト活動を運用チームに移管し、本番環境でのモニタリングによって品質を確保する開発手法
3. C　リリースの頻度を抑えて1回ごとの変更を大きくし、運用の安定性を高めるためのプロセス
4. D　開発（テストを含む）と運用が共通のゴールのために協力し、相乗効果を生み出す組織的アプローチ

1. A　テストウェアの品質向上
2. B　テスト担当者の人数の削減
3. C　開発とテストの連携の向上
4. D　テストの有効性・効率性の向上

1. A　テストベース
2. B　テスト対象
3. C　アプローチと責務
4. D　チームの規模

1. A　性能効率性、互換性、使用性、セキュリティをチェックする
2. B　機能完全性、機能正確性、機能適切性をチェックする
3. C　保守性、移植性、信頼性をチェックする
4. D　コードの内部構造を受け入れ可能なレベルまでカバーする

1. A　変更の大きさ
2. B　既存システムの大きさ
3. C　保守担当者の人数
4. D　変更のリスクの度合い

1. A　テスト計画書やテストケースはテストウェアであるため、静的テストの対象にならない
2. B　レビューの対象はソースコードと設計書に限られ、要件仕様書や契約書は対象にならない
3. C　法的な理由で解析が認められていない第三者の実行可能コードも、ツールで自由に静的解析してよい
4. D　静的解析は、モデルやコードのように、チェックするための構造を持つ作業成果物に適用する

1. A　要件を文書化しなくても済むようになり、ドキュメント作成の工数を省ける
2. B　要件に関する誤解を防ぎ、要件の変更をより早く理解して実装できる
3. C　テスト担当者がテストに関わる時間を減らし、テスト工数を大幅に削減できる
4. D　変更の影響がすぐに分かるため、リグレッションテストを行う必要がなくなる

1. A　マネージャー
2. B　レビューリーダー
3. C　書記（記録係）
4. D　モデレーター（ファシリテーター）

1. A　最も形式的なレビューで、メトリクスを収集してプロセス改善に用いる
2. B　作成者が主導し、作業成果物の内容をレビューアに説明しながら進める
3. C　技術的に適格なレビューアが行い、モデレーターが主導する
4. D　定義されたプロセスに従わず、文書化された成果物も必要としない

1. A　6
2. B　3
3. C　4
4. D　5

1. A　75%
2. B　100%
3. C　90%
4. D　60%

1. A　4
2. B　8
3. C　2
4. D　6

1. A　「-」：その条件はそのルールでは実行不可能／「N/A」：その条件の値は結果に無関係
2. B　「-」：そのルールではアクションが発生しない／「N/A」：アクションが発生する
3. C　「-」：その条件の値は結果に無関係／「N/A」：その条件はそのルールでは実行不可能
4. D　「-」：その条件は満たされない（偽）／「N/A」：その条件の値がまだ決まっていない（未定義）

1. A　実行不可能な列を削除して簡略化し、結果に影響しない条件がある列を統合して最小化できる
2. B　結果に影響しない条件がある列を削除して簡略化し、実行不可能な組み合わせの列を統合して最小化する
3. C　最小化アルゴリズムの詳細な手順を理解し、適用できることがシラバスの学習目標に含まれる
4. D　簡略化や最小化を行うと実行可能な列が失われるため、すべての列を残したまま使う

1. A　3
2. B　8
3. C　12
4. D　4

1. A　欠陥のある各ステートメントを実行しているので、コード内のすべての欠陥を検出できたことが保証される
2. B　すべての実行可能ステートメントを通過しているので、すべてのブランチも通過したことが保証される
3. C　欠陥のある各ステートメントは実行されているが、データに依存する欠陥は検出できないことがある
4. D　すべての判定の結果を少なくとも1回ずつ評価しており、判定ロジックをすべてテストしたことが確認できる

1. A　一度も実行されないステートメント内の欠陥
2. B　どの判定にも関係しない、直列に並んだコードの中の欠陥
3. C　if文の偽側でしか実行されない処理の欠陥
4. D　コード内の特定のパスの実行を必要とする欠陥

1. A　インターフェース
2. B　入力
3. C　論理
4. D　出力

1. A　テストのガイドラインとある程度の一貫性を与えることができる
2. B　機能テストには使えるが、使用性などの非機能テストには使えない
3. C　チェックリストは経験ではなく、要件仕様書から体系的に作成する必要がある
4. D　ハイレベルなチェックリストを使うほど、ばらつきが減り再現性が高くなる

1. A　ネガティブなテスト → ポジティブなテスト → 非機能のテスト
2. B　ポジティブなテスト → ネガティブなテスト → 非機能のテスト
3. C　ポジティブなテストのみを作成し、ネガティブなテストは作成しない
4. D　非機能のテスト → ポジティブなテスト → ネガティブなテスト

1. A　プロジェクトリスクと品質リスクの分析に参加し、リリース全体のテスト計画を立てる
2. B　プロダクトのリリースを見据えて、プロダクトバックログを定義・再定義する作業に参加する
3. C　リリース全体を見据えて、すべてのイテレーションに共通するテストアプローチの土台を作る
4. D　ストーリーの詳細なリスク分析と試験性の判断を行い、テストタスクに分解して工数を見積もる

1. A　終了基準はテスト実行の結果を見てから、テスト完了の段階で定義する
2. B　開始基準と終了基準はテストレベルごとに定義し、テスト目的によって異なる
3. C　開始基準と終了基準は組織全体で統一し、テストレベルによって変えない
4. D　開始基準が満たされていない状態で活動を始めても、困難さやリスクは変わらない

1. A　外挿／イテレーティブなSDLC
2. B　三点見積り／シーケンシャルなSDLC
3. C　ワイドバンドデルファイ／シーケンシャルなSDLC
4. D　比率に基づく見積り／イテレーティブなSDLC

1. A　リスク分析の結果に基づき、最も重要なリスクをカバーするテストケースから実行する
2. B　ステートメントカバレッジなどで最も高いカバレッジを達成するテストケースから実行する
3. C　ステークホルダーが定義した要件の優先度に基づいて、テストケースを順に実行する
4. D　テストケースの依存関係に基づき、前提となるテストケースから順に実行する

1. A　第三象限（ビジネス指向、プロダクトを批評する）
2. B　第二象限（ビジネス指向、チームを支援する）
3. C　第四象限（テクノロジー指向、プロダクトを批評する）
4. D　第一象限（テクノロジー指向、チームを支援する）

1. A　計算ロジックの誤りにより、顧客への請求額が間違って算出される
2. B　外部委託先が倒産し、モジュールが納品されない
3. C　ピーク時の応答時間が要件を満たさず、利用者が操作を待たされる
4. D　セキュリティの脆弱性を突かれ、顧客の個人情報が外部に漏れる

1. A　リスクタイプに適した経験やスキルを持つテスト担当者を選ぶ
2. B　リスクを保険などで第三者に移転する
3. C　適切なレベルのテストの独立性を適用する
4. D　適切なテスト技法とカバレッジレベルを適用する

1. A　テストに支障をきたすもの、およびその回避策
2. B　テストに関連する学習した教訓
3. C　テスト期間中に新たに発生したリスクと変更されたリスク
4. D　テストの進捗状況（前倒し・遅れなど）

1. A　開発・テストプロセスの改善のためのアイデアを提供する
2. B　欠陥を作り込んだ開発担当者の責任を追及する
3. C　欠陥の処理と解決に責任を持つ人に、問題を解決するための十分な情報を提供する
4. D　作業成果物の品質を追跡する手段を提供する

1. A　テスト実行およびカバレッジツール
2. B　テスト設計および実装ツール
3. C　コラボレーションツール
4. D　非機能テストツール

1. A　繰り返しの手作業が減って時間が節約され、テスト実行時間を大幅に短縮できる
2. B　ツールの導入、テストスクリプトの保守、プロセスの変更に必要な労力の見積りが正確でない
3. C　カバレッジなどの評価の客観性が向上し、より一貫性と再現性のある結果が得られる
4. D　テストのマネジメントやレポーティングの支援により、テストに関する情報へのアクセスが容易になる