Background
2024年夏から、Advanced Level Specialist テスト自動化エンジニアのCBTによる資格認定試験が始まります。（期間限定ですが）
自分は受ける予定なので、復習するにあたり、ISTQBの問題を使う。
英語を日本語しておいた方が楽だから翻訳を行った。
他の受講予定の人たちにもお役に立てればと思って、Qiitaに投稿しました。
たぶん、日本語のドキュメントが1系なので、ISTQB 1系の問題が参考資料になると思う。
Sample Exam – Questions Version 1.3
回答はこちら
ver 2.x版はこちら
尚、翻訳の誤植等はお許しください。
※最適な文言があれば、ご指摘ください！修正します
1. Introduction and Objectives for Test Automation
Q1. 手動テストよりテスト自動化の利点として考えられるものはなにか？
a) テストに必要な時間が長くなり、カバレッジが増える
b) テストに必要な時間が短く、カバレッジが増える
c) テストに必要な時間が長くなり、カバレッジが減る
d) テストに必要な時間が短く、カバレッジが減る
Q2. 重要なテスト自動化プロジェクトで技術的成功要因はどれか？
a) テスト自動化アーキテクチャは学びやすさを考慮して設計する
b) テスト自動化アーキテクチャはすべての手動テストを自動化できることをサポートする
c) テスト対象が自己文書化されている
d) GUI操作やデータがグラフィカルインターフェースと統合されている
2. Preparing for Test Automation
Q3. 複雑なシステムの機能テスト自動化を決定する。主要ツールベンダーを調査したが、非対応のためツールが使えないと判断した。エンジニアとともに独自実装のカスタムインターフェースを用いて自動化することにした。このアプローチで注意すべきこと２点選べ
a) リリース前にインターフェースが無効になっていない場合、セキュリティリスクが起きる可能性がある
b) テストインターフェースのパフォーマンスがリアルインターフェースより早い可能性がある
c) テスト自動化の開発の労力が、プロダクションの期待寿命に見合わない
d) 干渉レベルが高いため、誤検知が発生する可能性がある
e) 干渉レベルが低いため、テスト結果がプロダクションの動作を正しく反映していない
Q4. 重要な機能をもつレガシーアプリケーションの自動化をしている。システムの機能追加の更新で3rd partyのソフトを利用することになる。3rd partyソフトはテストされているが、既存と新しいソフトのIFに問題がある。既存のテスト自動化を拡張し、双方のIFのテストを行う。どのようなアプローチがよいか？
a) 双方のシステムを含めた全体のシステムのテスト自動化を開発する
b) 3rd partyとともにAPIを通してテスト自動化が可能かを調査する
c) 3rd partyのGUIを通してテストする新しいテスト自動化を作る
d) GUIテスト自動化をCLIに置き換えられるかを調査する
Q5. 評価している機能テスト自動化ツールが費用対効果が良いものであり、重要な技術的基準を満たしている。しかし、ツールの多くの機能は使われない見込み。そのため、複雑で混乱を招く可能性がある。次のアクションとして適切なものはどれか？
a) ユーザーフレンドリな別のツールを探す
b) 不要な機能をOFFにする設定ができるかを調べる
c) 長期的かつ包括的なトレーニングを計画する
d) よりユーザーフレンドリなIFを提供できる追加のツールを検討する
Q6. テスタビリティを設計するとき、一つの特徴としてテストがシステムのなかにアクセスできるIFを持ち、実際の結果と期待値を検証できるようにする。この特性を何というか？
a) 観測性 (Observability)
b) 可制御 (Controllability)
c) 保守性 (Maintainability)
d) 相互操作性 (Interoperability)
Q7. テスト対象の設計で、テスタビリティで考慮すべきことはなにか？
a) 相互操作性 (Interoperability)
b) 可制御 (Controllability)
c) 保守性 (Maintainability)
d) 可搬性 (Transportability)
3. The Generic Test Automation Architecture
Q8. generic テスト自動化アーキテクチャ(gTAA) でどのレイヤーが手動テストケースの設計、テスト自動化ケースの作成をカバーしているか？
a) テスト適合性 Layer
b) テスト定義 Layer
c) テスト生成 Layer
d) テスト柔軟性 Layer
Q9. テスト自動化の設計している。gTAAに基づきテスト自動化アーキテクチャを作成しようとしている。要求を満たすため、テスト自動化エンジニアはどのようなことを考慮すべきか？
Requirement
- テスト自動化アーキテクチャは技術を通して独立性を保つ。例）同じテストスイートが異なるテスト環境、異なる技術で利用できる
- テスト成果物は移植可能である
- ベンダー中立性
- テスト自動化アーキテクチャが保守性があり、保守コストを最小限にする
- 高度エンジニアが構築しても、一般エンジニアでも保守できることが望ましい
- 次の２年間、大きいプロジェクト予算があるが、その後は予算は減らされる
a) テスト自動化システムがテスト対象(SUT)と操作するための通信プロトコル
b) システムで保守される自動化テストケースの数
c) 実装でサポートされるテストの役割
d) 実装における抽象化の利用
Q10. テスト自動化アーキテクチャでテスト実行とテスト定義を分離することが重要なのはなぜか？
a) 実行のスピードを上げることができる
b) 実行で使われるツールの知識なしでテスト定義ができる
c) 実行中に必要に応じてテスト定義を追加することができる
d) テスト定義Layerは、さまざまなツールやIFとともにテスト実行するために必要な適合性を提供する
Q11. テスト適合Layerを設計するとき、どのようなことが起きるか？
a) テスト手順の解釈、コンパイルアプローチの選択
b) データドリブン、キーワードドリブン、パターンベースド、モデル駆動のテスト定義の選択
c) 手動もしくは自動テスト生成の選択
d) テストインターフェースのシミュレートや観測のために使うツール選定
Q12. テスト自動化にとって、テスト対象の法的、標準要件を考慮する最適なタイミングはいつか？
a) テスト自動化システムを開発時
b) テスト対象を実装時
c) テスト自動化アーキテクチャを設計時
d) テスト自動化フレームワークを作成時
Q13. テスト自動化プロジェクトで、ビジネスシナリオを自動化し、受入テストとして使う。ビジネスシナリオはよく定義され、受入テストで繰り返す。目的はいくつかのリグレッションテストとして同じシナリオをテスト自動化で実行する。構造化スクリプティングが使われて、テスト自動化で使われる機能ライブラリを開発するのに使う。これを達成するために、どのようなスクリプティング技術を使うべきか？
a) シナリオドリブンスクリプティング
b) キーワードドリブンスクリプティング
c) プロセスドリブンスクリプティング
d) リニアスクリプティング
Q14. テスト自動化を開発し、レガシーシステムがインフラマイグレーションさせるために使う。この間、スクリプトは基本的な機能の検証をする。シンプルで早いことが要件である。スクリプトの保守性は考慮しない。ソフトウェアの変更が起こることが予想されないからです。どのスクリプティングアプローチがよいか？
a) 構造化スクリプティング
b) データドリブンスクリプティング
c) キーワードドリブンスクリプティング
d) リニアースクリプティング
Q15. gTAAを用いてテスト自動化システムを構築する。レビューの結果、ユーザーIFよりもコマンドライン レベルにテスト自動化は焦点を置き、ユーザーIFの早く・継続的な変化に対応する。コマンドラインIFはすべての機能にアクセスでき、リリースされるプロジェクトの一部になる。ここから、gTAA標準から今回のテスト自動化システムでスコープアウトになるものはどれか？
a) テスト定義：テストデータコンポーネント
b) テスト適合：GUIコンポーネント
c) テスト生成：テストモデルコンポーネント
d) テスト実行：ユーザーIFコンポーネント
Q16. テスト自動化アーキテクチャからテスト自動化システムを実装している。テスト対象の他のシステムとの通信は安定している。テストインターフェースはGUIを通してである。テスト自動化アーキテクチャのどのコンポーネントを除外すべきか？
a) テスト生成Layer
b) テスト適合Layerのシミュレータ
c) テスト実行Layerのテスト実行
d) テスト適合LayerのGUI
Q17. 再利用に関して正しいものはどれか？
a) テスト自動化アーキテクチャで構築し、テスト自動化システムで保守・改善される
b) テスト自動化アーキテクチャとテスト自動化システム両方で構築し、テスト自動化アーキテクチャで保守される
c) gTAAでのみ適用される
d) テスト自動化システムで構築され、テスト自動化アーキテクチャで保守・改善される
4 Deployment Risks and Contingencies
Q18. テスト自動化を実装して組織に導入したい。重要度が変化する多くのシステムを持ち、一度テスト自動化が成熟すればメリットがある。そのため、パイロットに取り組む。テスト自動化システムにふさわしいプロジェクトをどうやって選ぶか？
a) 高い可視性のプロジェクトでパイロットの成功をハイライトできるようにする
b) 重要でないプロジェクトでテスト自動化システム起因による遅延を軽減する
c) 単純で簡単に自動化できるプロジェクト
d) 成熟してなく、開発途中の新しいプロジェクト
Q19. テスト自動化ツールのパイロットをする。適切なターゲットプロジェクトを決め、計画し、実施した。次のステップは何をするか？
a) 重要なプロジェクトで追加のパイロットを実施し、本当に必要な時に機能するかを確認する
b) ささいなプロジェクトで追加のパイロットを実施し、時間要件が高くならないことを確認する
c) 関係者の意見を集め、結果を評価する
d) パイロットプロジェクトメンバー内で評価し、経営層へのレポートを作る
Q20. 強く保守性の高いテスト自動化システムを作っている。５年間は利用したいため、保守性が重要である。いくつかのことは完了している。保守性の主要な要素でまだ対応されてないものはなにか？
DONE
- システムの全ての変更に対する影響分析プロセスを構築
- テスト自動化システムの利用方法ドキュメント化
- 3rd-partyの連絡先を含めた依存関係をドキュメント化
- テスト自動化システムがテスト対象の環境とは別の環境で実行されることを確認した
a) テスト自動化システムをモジュール式になる必要があり、必要に応じて主要なコンポーネントを交換できるべき
b) テスト自動化システムはgTAAのコピーであるべき
c) テスト対象がテスト自動化システムとおなじ環境に存在すべき
d) テスト自動化システムがテスト自動化フレームワークと統合しなければならない
Q21. 新しい機能をいれるためにテスト自動化システムを更新した。既存の機能に悪影響がないことを確認するために、どうしますか？
a) テスト自動化システムの新旧を比較して、違いの影響を評価する
b) 静的にチェックして新旧テスト自動化システムが同じであることを確認する
c) 新しいテスト自動化システムでつかわれるスタブやドライバーが同じであることを確認する
d) テスト対象のリリースノートを確認し、新しいテスト自動化システムが正しく動くであろうことを確認する
Q22. テスト自動化システムで標準的な命名規則が重要なのはなぜか？
a) テスト自動化の実行が早くなる
b) 新しいメンバーが参加した時に学ぶのが簡単
c) テスト自動化の標準が変更になった時、グローバルな置換をサポートする
d) テスト自動化フレームワークからテストスクリプトを分離できる
5 Test Automation Reporting and Metrics
Q23. ソフトウェアの品質が改善していることを可視化しないとテスト自動化の成果を評価することができない。テスト実行の成功・失敗数レポートでは不十分でもっと詳細の情報をダッシュボードで提供することが求められている。どのような情報を提供すれば良いか？
a) できない。情報は毎テスト実行後に手動で取得する必要がある
b) 自動テストウェアがDBに情報を格納し、成功・失敗のトレンドをダッシュボードで作成・表示する
c) 自動テストウェアが各テスト実行の結果をスプレッドシートにレポートし、詳細の結果を表示することができる
d) テスト自動化エンジニアは実行中に情報を記録し、グラフィカルツールでレポートを作成し、マネージャに提供する
Q24. 終業時に時間のかかるテスト自動化リグレッションテストスイートを実行する。５時間で終わるべきなのに、たまに次の朝までに完了していない時がある。問題原因特定するために最適なアプローチはどれか？
a) 日の始まりからテスト実行し、目視で監視する
b) ベンダーのレポートツールを評価し、テスト進捗を測定する
c) 夜勤スタッフを補充し、夜間実行を監視する
d) テスト実行結果を自動で収集する
Q25. テスト自動化の結果レポートを実装する時、読み手がテスト実行進捗を素早く評価できるためのいい方法は何か？
a) スプレッドシート
b) 信号機
c) 完了率を含めた詳細レポート
d) 結果のデータベース
Q26. デイリーのテスト自動化の結果の配信を求められている。e-mailで配信するに、これら情報を提供するために重要な特徴は？
a) 共通の3rd partyツールに統合する
b) 手動コメントで補足することができる
c) テストログライブラリを公開する方法を提供する
d) オーディオメッセージを収録できて、テスト結果に添付する
Q27. 500のテスト自動化スイートがあり、問題なく動いていた。後半のいくつかのテストが最近失敗している。分析結果、前半のテストで検知できていないテスト対象の不具合が原因だった。もっと多くの情報が必要で、偽陰性のテストを特定したい。どのオプションを使うと、問題特定に役立つか？
Option
- テストケースの実行のステータス（失敗・成功）
- 各テストケースの各ステップのタイミング情報
- テスト対象に関する動的な情報
- テストケースのすべてのアクション、再現できるようにする
- エラーが発生したステップの失敗情報
a) 1,2,3
b) 2,4,5
c) 2,3,5
d) 1,4,5
Q28. テスト実行レポートを公開するとき、どのキー属性を含むべきか
a) テストケースステップ
b) テスト環境
c) テスト対象の信頼性の評価
d) 失敗の主原因
6. Transitioning Manual Testing to an Automated Environment
Q29. ソフトウェアは比較的安定していて、４半期に更新がされていて、品質が重要である。Vモデルライフサイクルを使っている。最近の課題は、リグレッションテストに必要な時間のコスト効果く、新機能のフローの妨げになっている。１番の課題はテストデータの作成、保存である。テスト環境は安定しているが、テストデータがプロダクションから頻繁に更新され、保守性の高いテスト自動化を作ることが困難である。自動化の取り組みで最も問題になることはどれか？
a) テストプロセスの成熟度
b) ソフトウェアプロダクトライフサイクルのステージへの自動化の適合性
c) 利用頻度
d) 自動化の複雑性
Q30. テスト自動化スクリプトでもっとも一般的な基礎はどれか？
a) gTAA
b) SUT
c) 手動テストケース
d) 機能要求
Q31. テスト対象の全体的な品質を確認する場合、テスト自動化リグレッションカバレッジの明確な目標はなんですか？
a) 大雑把さ
b) 広さ
c) 深さ
d) 広さと深さ
Q32. テスト自動化システムに新しい機能が実装された時、誰がテスト自動化エンジニアにフィードバックすべきか？
a) ビジネスアナリスト
b) シニアマネージャ
c) ドメインエキスパートのテスト設計者
d) システム責任者
Q33. 欠陥の確認テストを自動化することの目的として最適なものはどれか？
a) 既存の自動化とのギャップを埋めるため
b) 修正が機能し、続けられることを確認するため
c) 欠陥を見つける時間を正当化するため
d) 構成管理プロセスをテストするため
7 Verifying the TAS
Q34. 自動化されたテスト環境と構築の信頼性に問題がある。環境を検証するテストスイートを作成し、その後に実際のテストを流すようにする。簡潔に環境のテストできるものはどれか？
a) 成功すると認識しているテストを実行し、成功することを確認する
b) 失敗すると認識しているテストを実行し、失敗することを確認する
c) 成功と失敗のテストを実行し、その通りの結果になることを確認する
d) 全体的なテスト自動化セットを実行し、結果を分析する。サブセットでは代表的なものにならない。
Q35. 月次でサービス更新されるシステムで、テスト対象を複数のバージョンのテストを同時に行なっている。テスト自動化システムは複雑で、異なる環境を通して一貫性を保つ必要がある。同じテスト自動化システムversionを異なるテスト対象で使われるようにするためにどうすればいいか？
a) テスト対象にパッチが適用される都度、テスト自動化を更新する
b) 手動テストに戻す
c) セントラルレポジトリからテスト対象にテスト自動化をインストールする
d) テスト結果の履歴を追跡するツールを開発する
Q36. プロダクションにリリースされたプロダクトのテスト自動化を実行した。テストは成功したが、本番では重要なバグが発見された。その機能はテスト自動化でカバーされているのに。テストが成功したのかを検証し、結果のレポートが正しいことも確認した。テストの有効性を確認するためなにをすべきか？
a) 失敗するテストを実行し、失敗することを確認する
b) 成功するテストを実行し、成功することを確認する
c) テストケースの事後条件が正しく検証されているかを確認する
d) テストデータを変更し、テストを再実行する
Q37. 安全性が重要な医療アプリケーションのテスト自動化スイートを実行準備している。テスト結果の正確性を確認するのにどのようなアプローチを取りますか？
a) 失敗するテストケースを実施し、それが失敗し続けることを確認する
b) 本番環境からデータを抽出し、テスト自動化で互換性を確認する
c) 類似のテスト対象でテスト傾向の履歴を調査する
d) テストスイートをゆっくり慎重に実行する
8 Continuous Improvement
Q38. テスト自動化システムのテストレースをレビューし、テスト自動化エンジニアがシステムエラーをいろいろな方法で扱っていることが分かった。さてどうする？
a) テスト自動化システムでエラー復旧プロセスを構築し、すべてのテストケースで使用するようにする
b) 復旧プロセスのライブラリを作成し、異なるスクリプト間で再利用する
c) キーワードドリブンに移行し、リカバリーを一つのキーワードにする
d) スクリプトで最適なwait処理を使い、システムエラーを回避する
Q39. テスト対象に対して安定したテスト自動化をもっている。ただ、ビジネス要求の変化でテスト対象がいくつかの新機能やAPIをつかったplug-inなどの更新が行われます。テスト自動化システムに対してどのような更新をすべきか？
a) API処理で失敗した時、フォールトトレラントになるように、テスト自動化システムの復旧機能を改善する
b) APIを含めたテスト自動化システムのドキュメントを更新する
c) API失敗による欠陥の増加が見込まれるため、ロギングを改善する
d) テスト自動化アーキテクチャの適合Layerを改修し、テスト自動化システムがAPIを介してテストできるようにする
Q40. テスト自動化システムの品質レビューをして、３年間更新されていないことを発見した。テスト自動化システムはテスト対象に対して適切に機能し、カバレッジも良い。しかし可能な限り効率的に動くことを確かめたい。効率性を向上させるために、どんなことを考慮すべきか？
a) 新しいテスト自動化コードに、一貫した命名規則を確立する
b) テスト自動化システムに迅速に変更を加えて、最先端に追いつく
c) 最新のライブラリをテスト自動化システムに組み込む
d) 3rd-partyのベンダーを雇い、現在のテスト自動化システムを評価する