第1章：テストプロセスにおけるテストアナリストのタスク

テストアナリストが、SDLC に応じてテスト分析・設計・実装・実行をどのように行うかを扱う。

問題1

あるアジャイルプロジェクトで、次の活動を行っている。

• 開発開始前から受け入れ基準を確認する
• イテレーションごとにテスト条件を識別する
• 開発者と頻繁に会話しながらテストを設計・実行する

この説明として最も適切なものを選びなさい。

1. アジャイルではテスト実行だけを開発後に行う
2. アジャイルではテストアナリストの活動をチーム全体で継続的に行う
3. アジャイルではテスト計画を一度だけ作成し、変更してはならない
4. アジャイルではレビューを行わない

問題2

次のうち、テスト分析の活動として誤っているものを選びなさい。

1. テストベースの曖昧さや欠落を識別する
2. テスト条件とテストベースの間のトレーサビリティを確立する
3. テスト対象のフィーチャーとテスト条件に優先度を付ける
4. テスト対象のソースコードを修正して欠陥を除去する

問題3

要件が頻繁に変更されているプロジェクトで、経験のあるテスト担当者が、異なるテストデータを使って複数回テストを実行する。テストケースの設計レベルとして最も適切なものを選びなさい。

1. 詳細なローレベルテストケースだけを作成する
2. 変更が落ち着くまでテストケースを作成しない
3. ハイレベルテストケースを作成し、必要に応じて詳細化する
4. テストケースを作らず、完全にランダムにテストする

問題4

テストケースを設計する際に、期待結果として考慮すべきものの組み合わせとして最も適切なものを選びなさい。

1. 画面に表示される文字列だけ
2. 画面出力、データの状態、テスト実行後の環境や後続処理
3. テスト担当者が予想した結果だけ
4. 実行前の入力データだけ

問題5

次の活動を、テスト実装に該当するものとテスト実行に該当するものへ分類しなさい。

問題6

テストアナリストが特に中心的に関与する活動の組み合わせとして最も適切なものを選びなさい。

1. テスト計画だけを作成し、分析・設計・実行は別の役割に任せる
2. ソースコード設計、コーディング、ビルド作成、リリース承認
3. テスト分析、テスト設計、テスト実装、テスト実行
4. プロジェクト調達、採用、契約、営業

問題7

V 字モデルでシステムテストを行う。テストアナリストの活動として最も適切なものを選びなさい。

1. コーディング完了後に初めてテスト計画を開始する
2. プロジェクト計画と並行してテスト計画を開始し、要件・設計から分析する
3. システムテスト実行が終わるまでテスト条件を定義しない
4. コンポーネントテストの成果物をテストベースにしてはならない

問題8

アジャイルプロジェクトにおけるテストアナリストの関わり方として最も適切なものを選びなさい。

1. 包括的なテスト文書を完成させるまで開発者と会話しない
2. 短く頻繁なコミュニケーションを行い、受け入れ基準やユーザーストーリーを確認する
3. アジャイルではレビューを行わない
4. テスト担当者はテスト実行だけを担当する

問題9

テスト条件をステークホルダーと共有する主な目的として、最も適切なものを選びなさい。

1. テスト担当者の解釈を一方的に承認させる
2. 範囲、リスク、期待結果、受け入れ基準について共通理解を作る
3. 要件レビューを不要にする
4. テストケースをすべてローレベルに固定する

問題10

テスト分析を始める前に確認すべき内容として、最も不適切なものを選びなさい。

1. テストベースとなる要件やユーザーストーリーが利用できるか
2. 関係するステークホルダーやドメイン知識にアクセスできるか
3. テスト目的、環境、利用可能なツールを把握しているか
4. 期待結果が不明確でも、確認せずにケースを大量作成するか

問題11

双方向トレーサビリティの説明として正しいものを選びなさい。

1. テストケースから要件へは追跡せず、要件からテストケースだけを追跡する
2. 要件からテスト条件・テストケースへも、テスト結果から要件へも追跡できる
3. トレーサビリティは自動化テストでだけ必要である
4. トレーサビリティは要件変更時に削除する

問題12

次のうち、テストケースの目的として最も適切なものを選びなさい。

1. 検索機能をできるだけ詳しくテストする
2. 有効な注文番号を入力したとき、注文詳細が 2 秒以内に表示されることを確認する
3. システムを十分に確認する
4. ユーザーが満足するようにする

問題13

テストウェアをどの程度詳細に文書化するかを決める要因として、最も適切なものを選びなさい。

1. テスト担当者が好むファイル形式と、テストケース数を最大にすること
2. すべてのプロジェクトで同一の詳細度にすること
3. プロジェクトリスク、文書の付加価値、規制、SDLC、トレーサビリティ要求
4. テストウェアを文書化せず、担当者の記憶だけに残すこと

問題14

次のうち、ローレベルテストケースの利点を活かしやすい状況を選びなさい。

1. 要件が頻繁に変わり、担当者の判断で探索する
2. 規制対応のため、手順・入力値・期待結果の再現性が必要である
3. 早期に論理的なテスト条件だけを作りたい
4. 異なるデータを使ってケースを再利用したい

問題15

テストスイートの実行順を決める際に、リスク以外の考慮事項として適切なものを選びなさい。

1. 必要な担当者、機器、データ、テスト対象機能の可用性
2. テストケースのタイトルの長さだけ
3. 低リスクケースを必ず最初に実行すること
4. 期待結果を定義しないこと

問題16

「目的にかなった」テスト環境の説明として正しいものを選びなさい。

1. テスト対象だけがあればよく、周辺機器や権限は不要である
2. 想定された利用環境を適切に再現し、テスト結果に影響する構成を管理できる
3. テスト実行中に環境を変更しても、実行済みケースへの影響を評価する必要はない
4. 本番環境と異なるほど、必ずテスト品質が高くなる

問題17

テスト実装で作成するテストデータとして最も適切なものを選びなさい。

1. 目的にかなった入力データと、必要に応じてデータベースへ投入する環境データ
2. 本番の個人情報を加工せずにコピーしたデータだけ
3. 期待結果を判断できないランダムな値だけ
4. テスト対象の画面に表示される文字列だけ

問題18

スクリプトなしのテストを適切に管理する方法として、最も適切なものを選びなさい。

1. 目的を持たせず、空いた時間にランダムに行う
2. タイムボックスとテストチャーターを使って実施する
3. 実行結果を記録しない
4. すべてのテストケースをローレベル化してから行う

問題19

テスト実行時にテストアナリストが追加で行う可能性のある活動として、最も適切なものを選びなさい。

1. 欠陥が集中し、追加テストが必要な領域を識別する
2. テスト対象の要件を無断で変更する
3. 修正コードを承認する
4. テスト結果を記録せず、記憶だけで報告する

問題20

故障を観察したとき、テストアナリストが最初に行うべきこととして最も適切なものを選びなさい。

1. 期待結果との不一致を分析し、再現に必要な条件を記録して欠陥を報告する
2. 失敗をすべてテスト環境の問題とする
3. 失敗したケースを削除する
4. 修正内容をテスト担当者が直接実装する

問題21

修正された欠陥の確認テストに加えて、関連する既存機能を再実行する主な目的として最も適切なものを選びなさい。

1. 修正によって別の場所に悪影響が出ていないか確認する
2. テストベースを削除する
3. すべてのリスクをゼロにする
4. 期待結果を新しく作らないようにする

問題22

テスト実行の進捗を判断するために必要な情報として、最も適切な組み合わせを選びなさい。

1. 実行状態、実際の結果、欠陥情報、トレーサビリティ、終了基準への状況
2. テスト担当者の感想だけ
3. 未実行ケースのタイトルだけ
4. 本番リリース後の問い合わせだけ

問題23

顧客要件はイテレーションごとに変化する一方、安全性に関わる高レベル設計と承認プロセスは計画的に管理されるハイブリッドプロジェクトがある。テストアナリストの関与として最も適切なものを選びなさい。

1. 計画段階だけ、または各イテレーションだけのどちらか一方に限定する
2. 計画・設計の一部に早期関与し、反復部分ではチームと相互作用的に分析・設計・実行する
3. 要件が変化するため、安全性に関するレビューには参加しない
4. すべてのテストケースをプロジェクト開始時にローレベルで固定する

問題24

テストアナリストが、要件の曖昧さを発見し、テスト条件を定義し、具体的な入力値と期待結果を決め、最後に実行順を含む手順を作成した。これらを正しく対応付けたものを選びなさい。

1. 曖昧さの発見＝分析、テスト条件＝分析、入力値と期待結果＝設計、実行順を含む手順＝実装
2. 曖昧さの発見＝実行、テスト条件＝実装、入力値と期待結果＝分析、手順＝設計
3. すべてテスト実行に該当する
4. 曖昧さの発見＝設計、テスト条件＝実行、入力値と期待結果＝実装、手順＝分析

問題25

法規制により、異なる担当者が同じテストを再現できる証跡が必要である。一方、業務要件はまだ変更される可能性が高い。この状況で最も適切な設計方針を選びなさい。

1. 変更があるため、最後までテストケースを作らない
2. まずハイレベルで条件を管理し、安定した範囲からローレベル化して、変更履歴とトレーサビリティを保つ
3. すべてを探索的テストにして証跡を残さない
4. 規制対応のため、要件変更を禁止する

問題26

「登録ボタンを押し、画面に完了と表示されたら合格」とするテストケースがある。登録データの保存と確認メール送信が仕様に含まれている場合、レビューで指摘すべき内容を選びなさい。

1. 画面表示だけでなく、保存データ、メール送信、実行後の状態を期待結果に含める
2. 画面表示があれば、バックエンドの結果は確認不要である
3. 期待結果を削除して探索的テストにする
4. メール送信は常に開発者だけが確認するため、テスト対象外にする

問題27

要件 R-17 の上限値が 100 から 120 に変更された。トレーサビリティを維持している場合、最初に確認すべきテストウェアの組み合わせとして最も適切なものを選びなさい。

1. R-17 に対応するテスト条件、境界値ケース、テスト手順、スクリプト、期待結果
2. R-17 と無関係な UI テストだけ
3. すべてのテストケースを無条件に削除する
4. 実行済み結果だけを確認し、未実行ケースは確認しない

問題28

高リスクの決済テストがあるが、決済用のテストデータはユーザー登録と商品登録が完了しないと作成できない。実行順の判断として最も適切なものを選びなさい。

1. 高リスクなので準備なしで決済テストを実行する
2. 依存する準備作業を前倒しし、データが利用可能になり次第、高リスクテストを優先する
3. 依存関係を無視してスケジュール上の順番だけで実行する
4. データがないので決済テストを削除する

問題29

システムテストの途中で、外部 API のモックを新しい版へ変更することになった。適切な対応を選びなさい。

1. 環境変更は実行済みケースに影響しないため、記録しない
2. 変更内容を記録し、実行済み・未実行ケースへの影響を評価して必要な再実行を決める
3. すべてのテストを成功扱いにする
4. 外部 API に関係しないテストもすべて削除する

問題30

リスクベースドテスト計画で、事前に設計した高リスク回帰テストと、未知のワークフロー問題を探す探索的セッションを組み合わせる。最も適切な実装方法を選びなさい。

1. 探索的セッションは無制限・無記録にする
2. 回帰テストはスイート化し、探索的テストはタイムボックスとチャーターで管理する
3. どちらも期待結果を定義しない
4. どちらも同じローレベル手順に固定する

問題31

テスト実行の結果、欠陥が特定のデータ変換モジュールに集中している。テストアナリストの次の活動として最も適切なものを選びなさい。

1. 発見済みの欠陥だけを報告し、関連リスクは更新しない
2. 欠陥集中領域を新しいリスク情報として再評価し、関連する追加テストを提案する
3. 欠陥が多いので、そのモジュールのテストを中止する
4. すべての欠陥を同じ 1 件にまとめる

問題32

次の終了基準のうち、最も適切なものを選びなさい。

1. 「十分にテストしたとテスト担当者が感じたら終了」
2. 「高リスク要件のケースを 100%実行し、未解決の重大欠陥が 0 件で、残余リスクを報告済み」
3. 「テスト担当者が疲れたら終了」
4. 「全ケースを作成したら、実行しなくても終了」

問題33

ハイブリッド型の開発で、要件は事前に承認されるが、2週間単位で実装・評価を繰り返す。テストアナリストの活動として最も適切なものを選びなさい。

1. 要件承認後は、最後のシステムテストまでテスト条件を見直さない
2. 反復ごとに変更されたテストベース、リスク、受け入れ基準を確認し、必要なテストを調整する
3. アジャイル要素があるため、テストウェアを作成しない
4. 事前承認された要件を優先し、反復中の利用者フィードバックを無視する

問題34

次のトレーサビリティ情報から、テスト分析と実装の欠落を示している状態への対応として最も適切なものを選びなさい。

1. R1の合格結果だけを再実行する
2. R2はテストケースがないため、テスト条件と実装状況を確認する
3. R3はテストケースがないので、要件を削除する
4. トレーサビリティはテスト完了後にしか作成できない

問題35

仕様書の「利用者は本人確認後に支払い方法を変更できる」と「支払い方法は注文確定後に変更できない」が、本人確認のタイミングを定義していない。テストアナリストの対応として最も適切なものを選びなさい。

1. テストアナリストの経験で本人確認のタイミングを決めてテストケースを作る
2. 両方の解釈をすべて実装してから比較する
3. 矛盾・曖昧さを記録し、関係者に状態遷移と期待結果を確認してからテスト条件を確定する
4. 支払い方法の変更テストを対象外にする

問題36

次の組合せのうち、ハイレベルテストケースとローレベルテストケースの使い分けとして最も適切なものを選びなさい。

1. 受け入れ条件のレビューには業務目的を表すハイレベルケース、再現性が重要な規制テストには詳細なローレベルケースを用いる
2. 受け入れ条件には内部APIの引数まで記載し、規制テストは目的だけを記載する
3. ハイレベルケースは自動化できず、ローレベルケースはレビューできない
4. プロジェクトの種類にかかわらず、常にローレベルケースだけを作成する

問題37

推薦結果の正解を一意に定義できない機能について、テストオラクルとして最も適切なものを選びなさい。

1. テスト担当者が気に入った推薦結果を正解とする
2. 「必ず同じ順序になる」という条件だけを置く
3. 禁止商品を含めない、指定カテゴリを一定数含めるなど、要求された性質・不変条件を確認する
4. 期待結果を定義せず、画面が表示されれば合格とする

問題38

注文確定テストで、前のテストが作成した注文データが残ると、次のテストが偶然成功することが分かった。最も適切な改善を選びなさい。

1. テストの実行順を固定するだけで、データの状態は管理しない
2. 各テストの前提データ、後処理、独立性を明確にし、再実行可能な環境を用意する
3. 偶然成功するテストは合格として扱う
4. すべてのテストで同じ共有アカウントを使い続ける

問題39

本番と異なる構成のテスト環境で高いカバレッジを達成した。テスト完了時の判断として最も適切なものを選びなさい。

1. カバレッジが高いので、環境差を無視して本番品質を保証する
2. 環境差が結果の妥当性に与える影響を評価し、未検証のリスクと追加テストを報告する
3. 環境差がある場合、すべてのテスト結果を破棄する
4. 本番環境でのテストだけを行い、テスト環境の結果は記録しない

問題40

共通認証サービスを変更した。回帰テストの選択として最も適切なものを選びなさい。

1. 認証画面のテストだけを再実行する
2. 変更箇所に直接依存する機能と、認証状態を前提とする高リスク業務フローを影響分析で選ぶ
3. 変更していない機能はすべて実行し、認証関連は除外する
4. 前回合格したテストは、変更後も結果が同じとみなす

問題41

欠陥報告の内容が「注文が失敗した」だけで、環境・入力・実際の表示・期待結果がない。テストアナリストが最初に行うべき改善を選びなさい。

1. 開発者が原因を推測できるので、そのまま登録する
2. 再現に必要な条件、期待結果、実際の結果、証跡、影響を補足して追跡可能にする
3. 再現できない欠陥はすべてクローズする
4. 失敗したテストケースの名前だけを報告する

問題42

次のテスト完了報告に不足している情報として、最も重要なものを選びなさい。

「計画したテストケースの95%を実行し、90%が合格した。残りは時間切れで未実行だった。」

1. テスト担当者の趣味
2. 未実行・未解決項目のリスク、欠陥の状態、環境差、リリース判断への影響
3. テストケースのファイル名をすべて本文に貼り付けること
4. 合格したケースの手順をすべて再掲すること

問題43

定期配送サービスの次期リリースで、次の状況が分かっている。

• 請求ルールは法改正により変更され、承認済みの業務要件と実装中の仕様に差がある
• 配送先住所の入力画面はイテレーションごとに変更されている
• 決済と配送連携は本番に近い環境がまだ準備できていない
• リリース判定では、未実行テストと残余リスクの説明が必要である

テストアナリストの進め方として、最も適切なものを選びなさい。

1. まず住所画面のローレベルケースを全件完成させ、要件の差は実装後に確認する
2. 本番相当環境がないため、テスト分析・設計を開始せず、環境完成を待つ
3. 請求ルールの矛盾を関係者と解消し、高リスクのテスト条件を先に定義し、変化する住所画面は適切な粒度で反復更新し、環境差と未実行範囲を完了報告へ残す
4. アジャイル要素があるため文書化を避け、テスト実行結果だけをリリース責任者へ提出する

問題44

医療機器ソフトウェアで、監査可能なテスト証跡が要求されている。テストベースには、患者データを扱う正常系要件、通信断時の安全要求、画面表示のユーザビリティ要求が含まれる。プロジェクトは反復型だが、安全要求の変更には承認が必要である。テストアナリストの成果物・活動として、最も適切なものを選びなさい。

1. 反復型なので、テスト条件や入力値を記録せず、口頭で結果だけ共有する
2. すべての要件を同じローレベル手順に固定し、反復中の変更を受け付けない
3. 安全要求は開発者だけの責任として、テストアナリストは画面の使用性だけを扱う
4. 要件・リスク・テスト条件・ケース・結果を双方向に追跡できる形で管理し、安全要求は承認された版に基づき、患者データは適切に匿名化して、変更時は影響を分析する

問題45

ハイブリッド型の開発で、注文上限が変更された。要件担当者は受け入れ基準だけを更新し、既存テストケースはそのまま実行するよう依頼した。テストアナリストの対応として最も適切なものを選びなさい。

1. 受け入れ基準が更新されたため、実装とテストケースは変更せず実行する
2. 上限値を含むテストケースだけを削除し、探索的テストに置き換える
3. 変更されたテストベースを確認し、影響するテスト条件・トレーサビリティ・ケース・優先度を更新してから実行する
4. ハイブリッド型では変更を扱えないため、次のリリースまでテストを停止する

問題46

外部決済 API の応答仕様が変更された。テストアナリストはテスト分析を完了していたが、モックの応答コード、テストデータ、期待結果、実行ログの版がそれぞれ別の管理場所にある。この状況で最初に改善すべきものを選びなさい。

1. すべてのテストをローレベルケースへ書き換える
2. モックの変更を無視し、従来の結果と一致するかだけを確認する
3. テストベース、モック、データ、ケース、結果を一意な版で関連付け、影響を受けるテストを再分析する
4. 外部 API は管理できないため、API のテストを対象外にする

問題47

リリース判定時点で、全体のテストケースの 95% は実行済みで合格している。しかし、決済失敗時の返金と監査ログの高リスクケースが未実行であり、未解決の重大欠陥も 1 件ある。テスト完了報告として最も適切なものを選びなさい。

1. 95% 合格なので、残りは統計的に無視して合格とする
2. 実行率を 100% に見せるため、未実行ケースを合格扱いにする
3. 重大欠陥が 1 件だけなので、影響を記載せず担当者の判断に任せる
4. 未実行の高リスク領域、重大欠陥、カバレッジ、残余リスク、リリース判断者の受入れ要否を明示する

問題48

同じ受け入れ基準について、テストケースを次のように管理している。仕様変更が頻繁な業務要件はハイレベルで保持し、安全規制に関係するテストは具体的な手順・データ・期待結果まで固定している。この設計の評価として最も適切なものを選びなさい。

1. すべてをローレベルに統一しないため、トレーサビリティが成立しない
2. リスク、変更頻度、規制、再現性を考慮した詳細度の使い分けであり、妥当である
3. ハイレベルケースは実行できないため、必ず不適切である
4. 安全規制がある場合でも、アジャイルでは文書化を省略すべきである

問題49

推薦機能は、利用者の行動履歴や時刻によって結果の順位が変わり、仕様にも「上位 5 件は利用者に有用なもの」としか書かれていない。テストアナリストがテストケースを設計する際の対応として最も適切なものを選びなさい。

1. 期待結果を定義できないため、推薦機能をテストしない
2. 常に過去の実行結果と完全一致することだけを合格条件にする
3. 担当者の主観で「良さそう」と判断し、根拠を記録しない
4. ドメイン専門家や利用者評価、業務ルール、許容範囲など複数のオラクルを合意し、決定的な条件と品質指標を分けて定義する

問題50

注文作成テストを独立に実行すると失敗しないが、テストスイートで実行すると、前のケースが残した管理者セッションと注文データによって後続ケースが偶然合格する。改善として最も適切なものを選びなさい。

1. スイート全体を毎回手動実行し、担当者が状態を確認する
2. 後続ケースが前のケースのデータを利用するよう、実行順を固定する
3. 合格しやすい共有データを増やし、実行時間を短縮する
4. 事前条件・事後条件・テストデータの所有を明確にし、必要な初期化や独立実行を検証する