趣旨
ここでは、ISTQBにて提供されている"Test Automation Engineer" Syllabusを自分なりに解釈（そのままの翻訳もあり）したものである
そのため、実際の試験と相違がある場合もありますのでご注意
原本↓
https://www.istqb.org/downloads/category/48-advanced-level-test-automation-engineer-documents.html
7 Verifying the TAS
7.1 Verifying Automated Test Environment Components
テスト自動化環境が期待通り動いているかを検証する必要がある。
以下、そのステップの詳細である
Test tool installation, setup, configuration, and customization
テスト自動化はいくつかのコンポーネントが構成される。それらの信頼性、繰り返しパフォーマンスの確保のために説明が必要である。コアは、実行コンポーネント、ライブラリ、データ、設定ファイルなどである。
設定工程は、自動でインストールするSCRIPTからマニュアルでの設定を含んでいる。テストツールは、サービスパックを基本的に持ち、互換性を確保するためのアドオン等を含む。
自動化されたインストールはメリットがある。異なるテスト対象で同じバージョンのテスト自動化でテストが実行できることを保障しうる。テスト自動化の更新はレポジトリを通して行われる。これは開発の標準的ツールと同じである。
Test scripts with known passes and failures
すでに通過したテストケースが失敗した時、基本的に何かが問題で、それを可能な限りフィックスすべきである。逆に失敗すべきところでテストが成功した場合、正しくないということを認知する必要がある。ログファイルの正しい生成、自動化ステップと同じくパフォーマンスのメトリックス、テストケース、SCRIPTの解体などの検証は重要である。異なるテストタイプ、レベルからいくつかのテストを実施するのは参考になる。
Repeatability in setup/teardown of the test environment
テスト自動化が各環境にて正しく動くため、その環境にインストール、アンインストールするシステマティックな方法が必要である。これが成功するのは、テスト自動化の構築、再構築が様々な環境にて違いがないように行われるときである。テスト自動化の設定管理はそれぞれにおいて忠実に設定値が作成されるものである。
Configuration of the test environment and components
テスト自動化を構成する様々なコンポーネントの理解やドキュメンテーションは、環境が変化したときに、それが影響を与え、変更を求めるどの自動化の側面かの必要なナレッジを提供する。
Connectivity against internal and external systems/interfaces
一度テスト対象にテスト自動化がインストールされると、チェックリストや前提条件が管理される必要があり、内外のシステムとの接続を有効にすることを確証する。テスト自動化の前提条件を構築することは自動化のインストール、設定を正しく行うのに必要である。
Intrusiveness of automated test tools
テスト自動化はテスト対象としばしば密接になる。それは設計によってなされ、ハイレベルな互換性を持つ。特にGUIレベルにて。しかし、ハイレベルの統合はマイナス面も持つ。テスト自動化がテスト対象に常駐することにより、テスト対象が異なる行動を起こす。またマニュアルで操作した時もしかり。テスト対象のパフォーマンスが影響を受けている。
例.) 侵入レベルの違い
- 外部IFからテスト対象に接するとき、新入レベルはとても低い。外部IFが電気信号、USB信号などである。この方法で、エンドユーザを最善の方法でシミュレートする。この方法では、テスト対象は全く変更しない。行動やタイミングはテストアプローチで影響を受けない。テスト対象と接することは、とても複雑になる。専用ハードウェアが必要になるかもしれない。
- GUIレベルのインターフェースの時、UIコマンドに侵入し、必要な情報を抜き出すようにテスト対象の環境に適応する。テスト対象の行動が直接的に変化がなくても、行動に結果影響するタイミングに影響する。複雑さは最初の例よりは低い。市販ツールがこのケースでよく使われる。
- テスト対象とテストIFを通じて接する。これらIF(API)の可用性はテスタビリティにとても重要になる。侵入レベルはとても高い。自動化テストはエンドユーザーが全く使わないIFを利用する。自動化にとって簡単で低コストになる。
開発者は、自動テストによって特定された不具合を最初に再現する必要がある。それが、手動で分析を支援になる。
Framework Component Testing
ソフトウェア開発同様、テスト自動化もコンポーネント単位でテスト、検証が必要。機能、非機能テストを含む。
GUIシステムでオブジェクト検証を提供するコンポーネントは幅広いオブジェクトクラスでテストが必要となる。正しくオブジェクト検証が機能することを構築するために。エラーログ、レポートは正確な情報を提供するべきである。
非機能の例として、パフォーマンス劣化の認識、システムリソースの利用状況を含む。
7.2 Verifying the Automated Test Suite
テスト自動化のテストスイートも、正しく一貫性があるかを検証する必要がある。異なる種類の検証チェックが使われ、テスト自動化がいつでも動くことを確保する。
自動化テストスイートの検証に以下のステップがある
- 認知の成功、失敗のテストケースの実行
- テストスイートのチェック
- フレームワークの新機能に焦点した新しいテストの検証
- テストの繰り返し実施の考慮
- テスト自動化スイートで十分な検証ポイントをチェック
それぞれの詳細は以下の通り
Executing test scripts with known passes and failures
成功するテストケースが失敗した時、なにかが根本的に問題で、すぐに直すべきである。逆に失敗すべきテストケースが成功した場合、テストケースが正しく動いていないことを認識するべきである。ログファイルの正しい生成、パフォーマンスデータ、テストスクリプトの設定、解除が行われることを検証することも重要である。異なるテストタイプやレベルでいくつかのテストを実施すると参考になる。
Checking the test suite
テストスイートが完全で、正しいバージョンであることをチェックする
Verifying new tests that focus on new features of the framework
新しい機能の自動化を最初にテストで使うとき、検証し、監視し、その機能が正しく動くことを検証する
Considering repeatability of tests
テストを繰り返すとき、テスト結果が常に同じである。信頼性の低い結果をだすテストケースはアクティブなテスト自動化スイートから外し、原因を分析すべきである。
断続的な失敗は分析すべきである。テストケースに問題があるかもしれないし、フレームワークに問題があるかもしれない。ログファイル分析で根本原因がわかる可能性がある。テストアナリスト、開発者、ドメインエキスパートのサポートで原因がわかるかもしれない。
Checking that there are enough verification points in the automated test suite and/or test cases
自動化テストスイートの実行し、機体結果が得られることを検証することを可能にすべきである。エビデンスはテストスイート、ケースが期待した通りに実施されたかを確認するために残すべきである。
このエビデンスには、各ケースの開始から終了までのログ、テスト結果、事後条件に達したかを検証するものを含む