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

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　変更が少ないことを前提に、詳細なテストドキュメントを事前にすべて作成しておく
2. B　動的テストはイテレーションごとには行わず、リリース前の最終段階でまとめて実施する
3. C　文書化を軽量化し、リグレッションテストを容易にするためテスト自動化を充実させる
4. D　手動テストでは、事前に大規模なテスト分析と設計を必要とする技法を中心に使う

1. A　ステークホルダーと合意した仕様をもとに、コードの完成後に自然言語でテストケースを作成する
2. B　テストを最初に書き、そのテストを満たすコードを書いてから、テストとコードをリファクタリングする
3. C　望ましい振る舞いを、Given/When/Then 形式などの理解しやすい自然言語のテストケースで表現する
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　1回のレビューでカバーしきれない作業成果物は、静的解析の対象に切り替える
3. C　作業成果物全体をカバーするために、レビュープロセスを2、3回行うことがある
4. D　レビューアの人数を増やし、1回のレビューミーティングで全体を確認する

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　0, 18, 65, 100
2. B　17, 18, 19, 64, 65, 66
3. C　18, 65
4. D　17, 18, 65, 66

1. A　3値BVAのほうが厳密で、2値BVAでは見落とされた欠陥を検出する可能性がある
2. B　2値BVAと3値BVAは、境界値の数が同じなのでカバレッジアイテムも同じである
3. C　2値BVAのほうが厳密で、3値BVAでは見落とされた欠陥を検出できる可能性がある
4. D　3値BVAのカバレッジアイテムは、すべて各パーティションの境界値になる

1. A　結果に影響しない条件を持つ列を統合して、列の数を最小化したデシジョンテーブル
2. B　すべての条件とアクションの値を、真・偽のブール値だけで示すデシジョンテーブル
3. C　実行不可能な組み合わせの列も削除せずに、すべての列を含めたデシジョンテーブル
4. D　条件やアクションの一部または全部が、数値の範囲や同値パーティションなど複数の値をとる

1. A　75%
2. B　100%
3. C　25%
4. D　50%

1. A　無効な遷移ごとに独立したテストケースにすることで、テストケースの数を最小にするため
2. B　ある欠陥が別の欠陥の検出を妨げる「欠陥のマスキング」を避けるため
3. C　1つのテストケースに含める遷移の数を、0スイッチカバレッジの定義に合わせるため
4. D　テスト実行の時間を短縮し、故障が発生した場合の再テストの工数を減らすため

1. A　ブランチカバレッジ100%を達成すれば、コード内のすべてのパスを実行したことになる
2. B　ブランチカバレッジ100%を達成すれば、ステートメントカバレッジも100%になる
3. C　両者は独立しており、一方の達成は他方に影響しない
4. D　ステートメントカバレッジ100%を達成すれば、ブランチカバレッジも100%になる

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　TC1
2. B　TC4
3. C　TC3
4. D　TC2

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　CI/CDのパイプラインでは、ビルドツールが版を管理するため構成管理の仕組みは含まれない
2. B　新しいベースラインを作成すると以前の記録は上書きされるため、過去のテスト結果は再現できない
3. C　構成管理の対象はソースコードとビルドファイルで、テストケースやテストレポートは含めない
4. D　テスト用に承認された構成アイテムはベースラインとなり、正式な変更コントロールでのみ変更できる

1. A　拡張性・展開の標準化をサポートするツール
2. B　テスト実行とカバレッジツール
3. C　DevOpsツール（デリバリーパイプラインを支援）
4. D　テスト設計および実装ツール

1. A　自動化すれば、ユーザー視点の手動テストも含めて手動テストは不要になる
2. B　オープンソースのツールを使えば、保守やアップデートを気にする必要がなくなる
3. C　一貫性と再実行性が高まることで、単純なヒューマンエラーを防げる
4. D　ツールを取得するだけで、導入や保守の労力をかけずに成功が得られる