第6章：テストツールおよび自動化

キーワード駆動テストと、テスト設計・テストデータ準備・テスト実行に使うツールを扱う。

問題1

キーワード駆動テストの説明として最も適切なものを選びなさい。

1. テストケースに画面座標やクリック位置だけを記述する方法
2. 業務上意味のあるキーワードとデータの列を、対応する自動化スクリプトが実行する方法
3. テストデータを使わずに自動実行する方法
4. すべてのテストを手動で実行する方法

問題2

キーワード駆動テストで、テストアナリストが主に担当する活動として最も適切なものを選びなさい。

1. すべての自動化スクリプトの内部コードを書く
2. ビジネスプロセス、キーワード、テストデータ、期待結果を作成・保守する
3. テスト対象の本番コードを修正する
4. 自動化フレームワークのライセンスを契約する

問題3

キーワード駆動テストが失敗したが、同じデータとテストケースを手動で実行すると失敗しなかった。この場合、最初に確認すべきものとして最も適切なものを選びなさい。

1. 失敗を必ずアプリケーション欠陥と判断する
2. 期待結果を記録せずに再実行を繰り返す
3. 直ちに本番環境のデータを削除する
4. キーワード、テストデータ、スクリプト、先行手順の影響

問題4

次のツールと用途の組み合わせとして正しいものを選びなさい。

1. aだけ正しい
2. aとbだけ正しい
3. bとcだけ正しい
4. a、b、cがすべて正しい

問題5

次のキーワード列が表すものとして最も適切なものを選びなさい。

Login → SearchOrder → CancelOrder → VerifyOrderStatus

1. 低レベルのクリック座標の一覧
2. 注文キャンセルという業務シナリオを表すテストケース
3. テストデータの匿名化手順
4. 欠陥分類法の一覧

問題6

キーワードとして ClickButtonAtX120Y300 より CancelOrder を使う利点として最も適切なものを選びなさい。

1. 期待結果が不要になる
2. テストデータを使えなくなる
3. 自動化スクリプトを作成しなくてよくなる
4. 業務上の意味を表し、画面実装の変更からテストケースを分離しやすい

問題7

UI のキャンセル確定ボタンの CSS セレクターが変更された。キーワード駆動テストで、通常修正対象になるものを選びなさい。

1. すべての業務シナリオの目的
2. 受け入れ基準をすべて削除する
3. テストデータの意味を無条件に変更する
4. CancelOrder キーワードの実装スクリプト

問題8

キーワード駆動テストのテストケースで、キーワードと関連付けるものとして最も適切なものを選びなさい。

1. 自動化担当者の給与
2. プロジェクトの全ソースコード
3. 本番利用者の個人情報を未加工で保存したデータ
4. キーワードが処理するテストデータと期待結果

問題9

キーワード実装をモジュール化する利点として最も適切なものを選びなさい。

1. すべてのテストケースを 1 つの巨大なスクリプトに統合できる
2. 期待結果を定義する必要がなくなる
3. テスト対象の変更を無視できる
4. 1 つの業務操作の変更を、そのキーワードの実装へ局所化しやすい

問題10

継続的インテグレーションを利用するイテレーティブプロジェクトで、テスト自動化開発の説明として最も適切なものを選びなさい。

1. 最終リリース直前に一度だけ行う
2. テスト対象の変更に合わせて継続的に開発・保守する
3. 実行結果が失敗しても変更しない
4. テストアナリストはキーワードを作成しない

問題11

キーワード駆動テストが失敗した。アプリケーションに欠陥があるかを確認するための最初の切り分けとして適切なものを選びなさい。

1. 自動化ツールを削除する
2. 失敗したテストを合格に変更する
3. 期待結果を削除する
4. 同じデータを使って同じテストケースを手動実行する

問題12

自動テストの「注文確定」が失敗したが、その前の「注文作成」が誤った商品 ID を登録していた可能性がある。この場合の分析として適切なものを選びなさい。

1. 注文確定の欠陥と即断する
2. 先行手順は常に正しいと仮定する
3. すべてのキーワードを削除する
4. 失敗したキーワードだけでなく、先行手順とデータの状態を確認する

問題13

自動化テストの失敗原因として、テストアナリストが切り分ける対象の組み合わせとして適切なものを選びなさい。

1. アプリケーションだけ
2. 自動化担当者の名前だけ
3. テストケースのタイトルの長さだけ
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

CI で毎回自動テストを実行しているが、画面変更のたびに大量のスクリプト修正が必要になる。この状況で考慮すべきこととして最も適切なものを選びなさい。

1. 保守コストは自動化では発生しない
2. すべてのテストを自動化すれば問題はなくなる
3. テストケースとスクリプトの分離をやめる
4. 自動化の利点だけでなく、スクリプトやキーワード実装の保守コストも評価する

問題21

テスト実行ツールの適用について、最も適切な説明を選びなさい。

1. システムテストでは絶対に使えない
2. コンポーネントテストだけで使う
3. レビューでのみ使う
4. 一般に統合テストやシステムテストで使い、API テストなどはコンポーネントテストでも使うことがある

問題22

テストツールを導入する前に確認すべきこととして、最も適切なものを選びなさい。

1. ツールを導入すること自体が目的になるか
2. 期待結果が定義できないか
3. テストアナリストの責任をすべて消せるか
4. 許容時間内にカバレッジや再現性などのテスト効率を高められるか

問題23

テスト自動化ソリューションを構築する際の協力関係として最も適切なものを選びなさい。

1. テストアナリストだけで全自動化コードを作り、他者を関与させない
2. 自動化エンジニアは期待結果を決め、テストアナリストは関与しない
3. 開発者はテスト結果を確認してはならない
4. テストアナリスト、開発者、自動化エンジニア、テクニカルテストアナリストが役割に応じて協力する

問題24

キーワード駆動テストのキーワードとして最も適切なものを選びなさい。

1. ClickElement(cssSelector="#submit")
2. 注文を確定する
3. Wait(3000ms)
4. driver.findElement(By.id("submit"))

問題25

キーワード駆動テストで、画面の「注文を確定する」キーワードがUI変更のたびに失敗する。役割分担として最も適切なものを選びなさい。

1. テストアナリストがすべてのUIロケーターを各テストケースに直接書き直す
2. テストアナリストは業務上の意味・期待結果を確認し、自動化担当が共通キーワード実装を修正する
3. 期待結果を削除して、キーワードが呼び出せれば成功とする
4. UI変更をテスト対象外にする

問題26

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

1. ユースケーステストは利用者の目的・シナリオを表し、キーワード駆動テストはその操作を再利用可能な意味単位で実行する仕組みであり、両者は併用できる
2. ユースケーステストとキーワード駆動テストは同じ概念なので、どちらか一方しか使えない
3. キーワード駆動テストは非機能テストにしか使えない
4. ユースケーステストでは期待結果を定義できない

問題27

自動化候補を選定する際、最も優先度が高い組合せを選びなさい。

1. 一度しか実行せず、期待結果も頻繁に変わる探索的テスト
2. 毎回実行する回帰テストで、手順と期待結果が安定している重要業務フロー
3. 要求が未確定で、成功条件が合意されていない機能
4. 自動化が困難で、結果を目視でしか評価できないテストだけ

問題28

あるテストは自動化に5日かかり、以後の手動実行を1回あたり2時間削減できる。ただし、毎回30分の保守が必要である。判断材料として最も適切なものを選びなさい。

1. 初期構築に時間がかかるので、必ず自動化しない
2. 削減時間だけを見て、保守時間は無視する
3. 実行回数、保守負荷、失敗時の調査、品質リスクを含めたライフサイクル全体で評価する
4. 自動化できるテストはすべて同じ優先度で導入する

問題29

個人情報を含む本番データをテスト環境へコピーしたい。テストアナリストの対応として最も適切なものを選びなさい。

1. 本番データを無加工でコピーする
2. 利用目的・アクセス制御を確認し、匿名化または合成データを用いて必要な特性を保つ
3. 氏名だけを削除すれば、他の識別情報はそのままでよい
4. テストデータの内容は期待結果に影響しない

問題30

自動テストが失敗したが、ログには「期待値と実際値が異なる」としか記録されていない。改善として最も有効なものを選びなさい。

1. 失敗したテストを削除する
2. 入力データ、環境、ステップ、期待値、実際値、スクリーンショットやログを追跡可能にする
3. すべての失敗を環境障害として扱う
4. 判定を常に成功にする

問題31

CIで同じテストが、同じビルドに対して一度は失敗し一度は成功した。最初に行う分析として最も適切なものを選びなさい。

1. 成功した実行を正しいと決め、失敗を無視する
2. テストの非決定性、環境差、データ競合、タイミング依存をログと再実行で調べる
3. テスト対象の欠陥と断定する
4. 待機時間を無条件に増やして終了する

問題32

同じログイン操作のセレクターが50個のテストスクリプトに重複して記述されている。保守性を高める設計として最も適切なものを選びなさい。

1. 50個すべてを手作業で個別修正する
2. ログインを共通キーワードまたは共通部品に集約し、変更点を一か所にする
3. ログイン検証を省略する
4. 失敗したスクリプトだけを再実行する

問題33

新しいテスト自動化ツールを導入する前の評価として、最も適切なものを選びなさい。

1. 機能数が最も多い製品を、対象プロジェクトを試さずに選ぶ
2. 代表的なシナリオで概念実証を行い、要求適合性、保守性、連携、報告、スキル、費用を評価する
3. ツールのデモ画面の見た目だけで決める
4. 導入後に初めて成功基準を考える

問題34

次のキーワード駆動テストの設計として、最も適切なものを選びなさい。

1. 業務上意味のあるキーワードとデータ・期待結果を分け、自動化実装の詳細をテストケースから隠す
2. 各キーワードにCSSセレクターを直接記載し、UI変更時に全ケースを修正する
3. 期待結果を自動化担当だけが決める
4. キーワード名を画面上のボタンIDと同じにする

問題35

「顧客を登録する」キーワードを、顧客種別・氏名・メールアドレスを引数として複数のテストで再利用する設計の利点として、最も適切なものを選びなさい。

1. 期待結果を一つに固定でき、どの顧客種別でも同じにできる
2. 操作の実装を共通化しつつデータを変えられ、変更時の修正範囲と重複を減らせる
3. テストデータの妥当性を確認しなくてよくなる
4. キーワードの内部実装をテストケースへ露出できる

問題36

データ駆動テストとキーワード駆動テストの関係について、最も適切な説明を選びなさい。

1. データ駆動はデータを変えて同じ手順を実行し、キーワード駆動は意味のある操作単位を組み合わせる。両者を組み合わせることもできる
2. 両者は同じ概念で、データ駆動では期待結果を持てない
3. キーワード駆動は自動化スクリプトを直接記述する方法である
4. データ駆動は非機能テスト専用である

問題37

自動テストが失敗した。ログには、期待値「注文確定」と実際値「注文保留」、同時刻の外部決済サービスのタイムアウトが記録されている。最初の切り分けとして最も適切なものを選びなさい。

1. 直ちに製品欠陥と断定する
2. 外部サービスの状態、仕様上のタイムアウト時の期待結果、テストデータ、再現性を確認して原因を分類する
3. 期待値を「注文保留」に変更して合格にする
4. 外部サービスを使うテストをすべて削除する

問題38

同じ自動テストが、コード変更なしでも10回に1回失敗する。改善方針として最も適切なものを選びなさい。

1. 失敗時だけ再実行して成功すれば、原因調査は不要とする
2. 非決定性の原因を特定し、データ・待機・並行実行・環境を改善する。隔離する場合も理由と復帰条件を記録する
3. テストを削除して失敗率を下げる
4. すべてのテストの待機時間を無条件に長くする

問題39

UI変更で、50個の自動テストのうち30個が同じログインボタンのロケーターで失敗した。保守の改善として最も適切なものを選びなさい。

1. 30個のテストケースにロケーターを個別に再記述する
2. ロケーターを共通キーワード実装やページ部品に集約し、業務シナリオと技術詳細を分離する
3. ログイン操作をテスト対象外にする
4. 失敗数を減らすため、ログイン確認をスキップする

問題40

テスト設計ツールとテスト実行ツールの組合せとして、最も適切なものを選びなさい。

1. テスト設計ツールは技法に基づくケース・データ作成を支援し、テスト実行ツールは実行・結果・ログの収集を支援する
2. テスト設計ツールは本番障害を自動修正し、実行ツールは要件を作成する
3. 両者は同じ目的なので、どちらか一方だけでテストプロセス全体を置き換えられる
4. テスト実行ツールには期待結果が不要である

問題41

本番データの匿名化で、氏名を置換したが、郵便番号・生年月日・購入履歴の組合せから個人を再識別できる可能性がある。最も適切な対応を選びなさい。

1. 氏名を消したので安全とみなす
2. 再識別リスクを評価し、必要な属性の一般化・置換・削除や合成データを検討し、テストに必要な相関は保つ
3. テストデータをすべてランダム値にして業務ルールを壊す
4. 本番データを開発者の端末へコピーして確認する

問題42

自動化候補Aは毎日実行する重要フローだが保守が難しい。候補Bは月1回の低リスク機能で、安定して自動化できる。候補選定として最も適切なものを選びなさい。

1. 保守が容易なBだけを選び、実行頻度とリスクは考慮しない
2. Aの便益・保守・実現性を評価し、重要度と実行頻度に見合うならAを優先する
3. 自動化が難しいAは必ず除外する
4. すべての候補を同時に導入する

問題43

新しい自動化ツールの概念実証で、代表的な業務フローは動作したが、既存CIへの連携、失敗時の証跡、担当者の保守方法は未確認である。次の判断として最も適切なものを選びなさい。

1. 代表フローが動いたので、全社導入を決める
2. 事前に定めた成功基準に対して未確認の観点を追加評価し、導入範囲・リスク・保守体制を合意する
3. すべてのツール評価を中止する
4. 失敗時の証跡は不要なので、CI連携だけ確認する

問題44

ECサイトの購入回帰テストをキーワード駆動で自動化する。現在、次の問題がある。

• テストケースには「商品を購入する」ではなく、画面座標とCSSセレクターが直接書かれている
• 本番由来の顧客データをそのままテスト環境へコピーしている
• 決済サービスのタイムアウト時に、失敗が製品・スクリプト・環境のどれか判別できない
• UI変更のたびに大量のケースを修正している

テストアナリスト、自動化担当、技術担当が協力して改善する方針として、最も適切なものを選びなさい。

1. 業務キーワード、データ、期待結果をテストケースに定義し、UI操作を共通キーワードへ隠蔽し、匿名化・合成データを用い、タイムアウト時の仕様と証跡を整備して原因を切り分ける
2. すべてのCSSセレクターをテストアナリストが各ケースへ再記述し、タイムアウトは常に製品欠陥として報告する
3. 本番データの再現性を優先して無加工コピーを続け、失敗時はテストを再実行して成功すれば終了する
4. UI変更を避けるため、購入回帰テストを削除して手動の探索的テストだけにする

問題45

保険会社がテストツール導入を検討している。候補ツールは、API実行・データ生成・結果レポートを提供するが、既存CIへの連携は追加開発が必要である。代表的な回帰テストを10本実行した概念実証では、手動より実行時間は短縮したものの、3本で誤検知が発生し、担当者はログから原因を特定できなかった。導入判断として最も適切なものを選びなさい。

1. 実行時間が短縮したので、誤検知と分析性は導入後に解決する
2. 追加開発が必要なので、候補ツールを即時に不採用にする
3. 10本の代表テストが動いたため、全テストを一度に移行する
4. 事前に定めた成功基準を、実行時間だけでなく誤検知率、失敗時の証跡・分類、CI連携、保守コスト、データ安全性まで広げ、改善後に再評価して段階導入を判断する

問題46

EC サイトの購入回帰テストをキーワード駆動で自動化する。現在、SearchProduct、AddToCart、Checkout、Pay、VerifyOrder のキーワードがあり、決済サービスはテスト環境によって応答が遅延する。UI のボタン名も頻繁に変更され、同じキーワードが複数のケースから利用されている。最も保守しやすい設計を選びなさい。

1. 各テストケースへ画面座標、待ち時間、決済 API の詳細を直接書き込む
2. UI 変更のたびにすべての業務シナリオを書き直し、遅延時は無条件に再実行する
3. 業務キーワードとデータ・期待結果をケースに保持し、UI/API/待機・タイムアウト処理をキーワード実装の共通部品へ分離して、失敗時に原因情報を記録する
4. 実装を隠蔽するため、Checkout と Pay を 1 つの巨大キーワードへ統合する

問題47

同じ自動テストが、コード変更のない同一ビルドで 10 回に 1 回失敗する。失敗ログには、画面のタイムアウト、外部在庫サービスの遅延、テストデータの重複、期待値不一致が混在している。最初の分析として最も適切なものを選びなさい。

1. 失敗を flaky と決めつけず、再現条件・環境・データ・外部依存・キーワードログを分離して収集し、製品欠陥・自動化欠陥・環境問題・データ問題を分類する
2. CI の結果を安定させるため、失敗した実行を自動的に合格へ変換する
3. 待ち時間を最大値まで増やし、原因を記録せず再実行する
4. 同じテストを 100 回実行し、1 回でも合格すれば問題なしとする

問題48

自動化ツールの概念実証で、代表的な 12 ケースは実行できた。しかし、実行結果の差分に業務上重要でない動的 ID が毎回含まれ、失敗時のスクリーンショットは取得できず、テストアナリストはキーワードデータを編集できない。次の判断として最も適切なものを選びなさい。

1. 代表ケースが動いたので、問題を残したまま全回帰テストへ展開する
2. テストアナリストが編集できないことは品質に関係しないため、評価項目から外す
3. 動的 ID を含む差分をすべて無視し、失敗は担当者が画面を確認する
4. 判定ルール、証跡、ロール分担、保守性を成功基準に追加し、少数ケースで改善を検証してから段階導入する

問題49

本番データを匿名化してテスト環境へ投入した。氏名は置換したが、郵便番号、生年月日、購入履歴の組合せで個人を再識別できる可能性があり、キーワード駆動テストのデータファイルには元の顧客 ID が残っている。最も適切な対応を選びなさい。

1. 氏名が変わっているので、そのまま利用し、問題はテスト後に削除する
2. 再識別リスクとデータファイルの参照を評価し、準同一識別子を一般化・置換するなど匿名化し、最小限の合成データへ切り替えてアクセスを制限する
3. 自動化を止め、担当者が個人情報を含むデータを手動で入力する
4. 顧客 ID だけをテストケースから削除し、データベース側の関連付けは確認しない

問題50

自動化スイートは 1 回の実行時間を 4 時間から 40 分へ短縮したが、画面変更のたびに 30% のケースが修正対象となり、失敗のうち 20% は環境起因、結果レポートには要件 ID がない。自動化の改善計画として最も適切なものを選びなさい。

1. 実行時間だけをさらに短縮するため、失敗したケースを削除する
2. 画面変更を禁止し、現在のスクリプトを維持する
3. キーワードの共通化、環境依存の分離、失敗分類・証跡、要件とのトレーサビリティ、保守時間を指標にし、改善効果を継続的に測定する
4. すべての環境起因失敗を製品欠陥として報告し、保守作業を開発者へ移管する