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

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　要件仕様書の欠陥は、実装段階で開発担当者が気づいて修正するため、後の工程には影響しにくい
2. B　欠陥はソースコードで見つかるものであり、要件仕様書などのドキュメントからは発見できない
3. C　SDLC初期の作業成果物の欠陥は、検出されなければ、後半の欠陥のある作業成果物につながることが多い
4. D　欠陥を含むコードが実行されると、どのような状況であっても常に故障を引き起こす

1. A　製品の販売価格、営業戦略、開発担当者の給与体系、組織の採用方針、広告宣伝の予算
2. B　ステークホルダー、チームメンバー、ビジネスドメイン、技術的要因、プロジェクトの制約
3. C　テスト戦略、テスト技法、自動化の度合い、カバレッジ、ドキュメントの詳細度、レポート作業
4. D　テスト対象、テストレベル、リスク、従うSDLCモデル、ビジネスコンテキスト

1. A　リスクを、その可能性・影響・リスク軽減に関する情報とともに列挙したもの
2. B　テストケースと要件の対応関係を、リスクレベルの高い順に整理した表
3. C　発見した欠陥を、再現手順や重要度、優先度、対応状況とともに一覧にしたもの
4. D　リスクの高い順にテストケースを並べ、実行の日程を割り当てたスケジュール

1. A　アジャイル開発ではテストマネジメントのタスクは存在せず、各開発担当者が自分のテストを個別に判断する
2. B　タスクの一部をアジャイルチームが担い、複数チームにまたがるタスクはチーム外のテストマネージャーが行うことがある
3. C　独立性を保つため、1人がテストをする役割とテストマネジメントをする役割を同時に担うことはできない
4. D　テストマネジメントをする役割は、チームの状況にかかわらず専任のテストマネージャーが担う必要がある

1. A　プロジェクトで1つの独立性のレベルを選び、全テストレベルで統一する
2. B　作業成果物を最もよく知る作成者自身に、すべてのテストレベルを任せる
3. C　テストレベルに応じて、複数の独立性のレベルでテストを行う
4. D　最も独立性の高い組織外のテスト担当者に、すべてのテストレベルを任せる

1. A　テストドキュメントの詳細レベル
2. B　テスト自動化の範囲
3. C　テスト技法とテストアプローチの選択
4. D　テスト対象のプログラミング言語

1. A　テストを先に書き、テストを満たすコードを書いてから、テストとコードをリファクタリングする
2. B　ユーザーストーリーの受け入れ基準から、システム設計の一環として受け入れテストを導き出す
3. C　コードを書いた後にカバレッジを測定し、未カバーの箇所を通るテストを追加していく
4. D　Given/When/Then 形式の自然言語で望ましい振る舞いを記述し、そこからテストを導き出す

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　100%のカバレッジを達成するには、各パーティションから少なくとも2つの値をテストする必要がある

1. A　無効な値は、テスト対象が無視または拒絶すべきもの、あるいは仕様に処理が定義されていないもの
2. B　同値分割法の100%カバレッジは、有効パーティションをすべて通すことで達成される
3. C　有効・無効の定義はシラバスで統一されており、チームや組織によって異なることはない
4. D　仕様書に処理が定義されていない値は、テスト対象が処理すべき有効な値と解釈する

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

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

1. A　テスト対象のコードの内部構造に基づいて、通過していない判定結果を特定できる
2. B　順序性のあるパーティションの境界付近に潜む欠陥を、少ないテストケースで見つけられる
3. C　条件の組み合わせを漏れなく体系的に識別でき、要件の相違点や矛盾の発見にも役立つ
4. D　条件の数が増えてもルール数はほぼ線形にしか増えないため、大規模な仕様にも適用しやすい

1. A　全状態カバレッジ
2. B　全遷移カバレッジ
3. C　1スイッチカバレッジ
4. D　有効遷移カバレッジ

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

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

1. A　ステートメント 100%、ブランチ 50%
2. B　ステートメント 100%、ブランチ 100%
3. C　ステートメント 75%、ブランチ 50%
4. D　ステートメント 75%、ブランチ 100%

1. A　ブラックボックステストだけでも、要件カバレッジから実際のコードカバレッジを測定できる
2. B　ホワイトボックステスト技法はコードの実行が前提なので、ドライランなどの静的テストには使えない
3. C　コードの構造を網羅的にテストするため、実装されていない要件の欠落も確実に検出できる
4. D　カバレッジを客観的に測定でき、カバレッジを高めるテストを追加するための情報を提供する

1. A　一般的すぎる項目や、自動的にチェックできる項目
2. B　機能要件、品質特性、GUIの設定などを参照する項目
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　AとBを同時に実行して、両方の結果を比較する
3. C　優先度に従い、優先度の高いAを先に実行する
4. D　依存関係を満たすため、Bを先に実行する

1. A　ユニットテスト、サービステスト、UIテスト
2. B　コンポーネントテスト、システムテスト、受け入れテスト
3. C　静的テスト、動的テスト、探索的テスト
4. D　機能テスト、非機能テスト、リグレッションテスト

1. A　リスクの可能性とリスクの影響／0より大きく1より小さい
2. B　リスクの可能性とリスクの影響／0以上1以下（0と1を含む）
3. C　リスクの発生源とリスクの検出可能性／0より大きく1より小さい
4. D　リスクの影響とリスクの対策費用／1以上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　開発プラットフォームとの互換性がツールによって確保され、移行の手間がなくなる