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

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　インクリメンタル開発モデル：V字モデル、ウォーターフォールモデル
2. B　シーケンシャル開発モデル：スパイラルモデル、V字モデル
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　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　40%
2. B　67%
3. C　100%
4. D　60%

1. A　20
2. B　21
3. C　19
4. D　どの値でも検出できない

1. A　パーティション内部の代表値に対する処理結果が誤っている欠陥
2. B　実装された境界が意図した位置からずれている、または省略されている欠陥
3. C　複数の条件の組み合わせに対するアクションが考慮されていない欠陥
4. D　特定のイベントが発生した後に、誤った状態へ遷移してしまう欠陥

1. A　16
2. B　8
3. C　24
4. D　4

1. A　状態表では、行がイベント、列が状態を表す
2. B　状態遷移図は無効な遷移を明示的に示すが、状態表は示さない
3. C　状態表は無効な遷移を空のセルで明示的に示す
4. D　遷移のラベルの一般的な構文は「アクション［イベント］／ガード条件」である

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

1: read(x)
2: if (x < 0) {
3:     x = -x
   }
4: print(x)

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

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　準備完了（Ready）の定義
3. C　完了（Done）の定義
4. D　イテレーションゴール

1. A　6 ± 2 人日
2. B　6 ± 12 人日
3. C　5 ± 2 人日
4. D　7 ± 4 人日

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

1. A　最下位のレイヤーのテストは粒度が細かいため、少数で妥当なカバレッジを達成できる
2. B　上位のレイヤーほど、テストの粒度が細かく、分離度が高く、実行が速い
3. C　上位のレイヤーほど、テストの粒度が粗く、分離が少なく、実行が遅くなる
4. D　レイヤーの数と名称は、ユニット・サービス・UIの3つに固定されている

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　DevOpsツール － テストケースやテストデータ、テストプロシジャーの作成を促進する
4. D　マネジメントツール － レビューや静的解析を行うテスト担当者を支援する

1. A　ツールに過剰に依存し、人の批判的思考の必要性を軽視する
2. B　テスト実行時間が短くなり、欠陥や品質に関するフィードバックが早くなる
3. C　テスト担当者が、より深い新しいテストの設計に時間を使えるようになる
4. D　カバレッジなどの測定値が得られ、評価の客観性が向上する