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

1. A　テスト対象の品質に対する信頼を積み上げる
2. B　開発担当者ごとの生産性を評価し、人事考課に反映する
3. C　故障を引き起こし、欠陥を発見する
4. D　ステークホルダーが根拠ある判断をするための情報を提供する

1. A　テストは欠陥を費用対効果よく検出し、欠陥はデバッグで除去されるため、品質向上への貢献は間接的である
2. B　テストはSDLCの最終段階で品質を評価する活動であり、リリース判定の情報は主にこの段階で提供される
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　テストの監査を容易にし、ITガバナンスの基準を満たすのに役立つ
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　早い段階で十分にテストすることで、SDLCの後半のテストを省略できるようにする考え方
3. C　より早い段階でのテストを提言するが、SDLCの後半のテストを軽視してよいという意味ではない
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　従うSDLCと開発プロセスの成熟度
4. D　レビュー参加者の年齢構成

1. A　ホワイトボックステスト技法：仕様ベース技法／経験ベースのテスト技法：構造ベース技法
2. B　ブラックボックステスト技法：経験ベース技法／ホワイトボックステスト技法：仕様ベース技法
3. C　ブラックボックステスト技法：仕様ベース技法／ホワイトボックステスト技法：構造ベース技法
4. D　ブラックボックステスト技法：構造ベース技法／ホワイトボックステスト技法：経験ベースのテスト技法

1. A　9
2. B　24
3. C　2
4. D　4

1. A　17, 18
2. B　18, 19
3. C　18 のみ
4. D　17, 18, 19

1. A　このテーブルでは判定できない
2. B　送料800円
3. C　送料無料
4. D　送料500円

1. A　37.5%
2. B　60%
3. C　50%
4. D　75%

1. A　イベントによって開始され、ガード条件によって限定されることがあり、瞬時に起きると想定する
2. B　イベントによって開始されるが、遷移に伴ってソフトウェアがアクションを起こすことはない
3. C　ガード条件が真になることで開始され、イベントによって限定されることがあり、瞬時に起きると想定する
4. D　イベントによって開始され、状態間の移動には処理時間に応じた一定の時間がかかると想定する

1. A　ステートメントテストとブランチテスト
2. B　パステストとデータフローテスト
3. C　条件判定テストとMC/DCテスト
4. D　APIテストとニューロンカバレッジテスト

1. A　制御フローグラフの2つのノード間の制御の遷移で、無条件のものと条件付きのものがある
2. B　if文やswitch文の判定結果を指し、ループの継続・終了の判定はブランチとして扱わない
3. C　判定における真の結果への遷移のみを指し、偽の結果や無条件の遷移はブランチに含まない
4. D　ソースコード中の実行可能なステートメントのことで、各ステートメントが1つのブランチに当たる

1. A　開発担当者が起こしやすいエラーの種類と、それに起因する欠陥の種類
2. B　テストケースのステートメントカバレッジの値
3. C　他の類似アプリケーションで発生した故障の種類
4. D　アプリケーションの過去の動作状況

1. A　一度作成したチェックリストは、項目の効果が変わらないため、長期間そのまま使い続けてよい
2. B　チェックリストがハイレベルな場合、実際のテストのばらつきはなくなり、再現性が高まる
3. C　チェックリストには、ツールで自動的にチェックできる項目もできるだけ多く含めるべきである
4. D　効果が薄れる項目が出てくるため、欠陥分析に基づいて定期的に更新すべきである

1. A　Given/When/Then 形式のシナリオ
2. B　ユーザーストーリーの「[役割]として…したい」という文
3. C　箇条書きの検証リストや、入出力のマッピングを示す表
4. D　プランニングポーカーのカード

1. A　テストの独立性、収集すべきメトリクス、テスト環境要件
2. B　リスクレジスター、テストの範囲、テスト目的、テストベース
3. C　予算とスケジュール、テストのコンテキスト、前提条件と制約
4. D　ステークホルダーの役割と責務、コミュニケーションの形態と頻度

1. A　シーケンシャル開発では認められるが、アジャイル開発では完了の定義を満たすまで続ける
2. B　ステークホルダーがテストせずに本稼働させるリスクをレビューして受け入れたなら許容される
3. C　他の終了基準がすべて満たされていない限り、時間切れや予算切れでは終了できない
4. D　テストの進捗に最も詳しいテスト担当者が、リスクを判断して終了を決めればよい

1. A　3,200人日
2. B　160人日
3. C　320人日
4. D　200人日

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

1. A　コンポーネントテストとコンポーネント統合テスト／自動化してCIに含めるべき
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　ソースコードが公開されているため、テストデータや結果が外部に漏えいしやすくなる