趣旨

ここでは、ISTQBにて提供されている"Test Automation Engineer" Syllabusを自分なりに解釈（そのままの翻訳もあり）したものである
そのため、実際の試験と相違がある場合もありますのでご注意
原本↓
https://www.istqb.org/downloads/category/48-advanced-level-test-automation-engineer-documents.html

3. The Generic Test Automation Architecture

3.1 Introduction to gTAA (generic Test Automation Architecture)

テスト自動化のarchtectureは以下のような考えをもって構築する

内外のメンバがテスト自動化開発をできるコンセプト、I/F等を定義する
テスト自動化の開発を効果的にするsimpleなcomponent開発をサポートする
テスト自動化を他でも再利用できるようにする
メンテナンスを楽にする
テスト自動化で必須機能を定義する

以下の原則に従うことを進めている
（オブジェクト指向の考えがベース）

Single responsibility: 一つの自動化スクリプトはカプセル化され、一つのresponsibilityのみ持たせる。（開発と同じで１コンポーネント、１ロールとシンプルにする）
Extension: 下位互換を保ちつつ、拡張できるコンポーネント実装にする（オブジェクト指向の開放/閉鎖原則）
Replacement: コンポーネントを置き換えできるようにする
Component segregation: componentを隔離し、不必要な依存関係をなくし、メンテナンス性を上げる
Dependency inversion: componentは抽象化して、特定のテストに依存しないつくりにする

テスト自動化architectureはツールのベンダーに依存しない、中立であることが望ましい。そのため、どんなソフトウェア技術で構築できるようにする
テスト自動化エンジニアは、実装のためのコーディングやドキュメント標準、best practice等を常に追っかけることが望まれる。

3.1.1 Overview of the gTAA

gTAAのhorizontal layerは以下の通り

Test generation: マニュアルと自動化のテストケース設計をsupportする
Test definition: テストスイート、ケースの定義・実装をsupportする
Test execution: テストケース実行、ロギングをsupportする
Test adaptation: テスト自動化に必要なI/F、API等を提供する。

各layerは、他のテストツール（テストマネジメントツール等）とのI/Fも含む。
テスト自動化は、incrementalに構築やPOCをすることを勧める。

経験上、自動化の理想像をいきなり追い求めると、結果が出るまで時間がかかり、目的が自動化になってしまう。そのため、少しずつ構築してOUTPUTを出していくことが望ましい。
以下、各layerの詳細。

3.1.2 Test Generation Layer

このlayerは以下をsupportする

マニュアルでテストケースの設計
開発、キャプチャ、テストケースを引き出す
モデルベーステスティングでモデルから自動でテストケースを作成

このlayerの利用目的

テストスイート構造を編集、操作
テストケースとテスト対象との関連付け
テスト設計のドキュメント化

以下の機能も有する

システムや環境等をモデル化
テスト方針の定義、テスト生成アルゴリズムの設定
生成されたテストとモデルとでトレース可能

3.1.3 Test Definition Layer

このlayerは以下をsupportする

テストケースを明示化
low levelのテストケースのためのテストデータ定義
テストケースの手順を明示化
テストケース実行のテストSCRIPTを定義
必要に応じて、テストライブラリへアクセスを可能にする（キーワード駆動）

このlayerの利用目的

テストケースの区分、制約、パラメータ化、生成
テストシーケンス、完全自立テストふるまいを明示化
テストデータ、ケース、手順のドキュメンテーション

3.1.4 Test Execution Layer

このlayerは以下をsupportする

テストケースの自動実行
テストケース実行のロギング
テスト結果のレポート

以下の機能を有する

テスト環境のsetup / tear down
テストスイートのsetup / tear down
テストsetupの設定、パラメータ化
テストデータ、ケースの解釈とそれを実行SCRIPTへ変換
システムに実行結果のロギングの仕込み
テスト実行中にシステムのレスポンスを分析
テスト自動化の結果を判定するためのシステムレスポンスの妥当性判断
テスト自動化の実行制御

3.1.5 Test Adaptation Layer

このlayerは以下をsupportする

テストハーネスの制御
システムとの相互作用
システムのモニタリング
システムのシミュレーション/エミュレーション

以下の機能を有する

技術中立なテスト定義、技術に特化した要求、テストデバイスの融合
システムと相互作用するためのアダプタ適用
複数のテスト環境・デバイスへのテスト実行配布

3.1.6 Configuration Management of a TAS

テスト自動化はいろんな開発サイクル・バージョンで実装され、互換性をもつことが求められる。過去のバージョンを確認、再現テスト等をおこなうことがある。
そのため、以下の構成管理が必要になる。

テストモデル
テスト定義、テストデータ、ケースライブラリの仕様
テストスクリプト
テスト実行エンジン、ツール、コンポーネント
システムとのアダプタ
シミュレータ、エミュレータ
テスト結果

3.1.7 Project Management of a TAS

テスト自動化もソフトウェアプロジェクトと同じであるため、ソフトウェア開発と同等の扱いになる。テスト自動化エンジニアは、Software Development Life Cycleを考慮する。

3.1.8 TAS Support for Test Management

テスト自動化はテストマネジメントもサポートする。
テストレポートはテストログ、結果を含み、テストマネジメントに自動的に提供される。

3.2 TAA Design

3.2.1 Introduction to TAA Design

テスト自動化architectureの設計の主活動は以下の通り

1. Capture requirements needed to define an appropriate TAA

テスト自動化アプローチの要求で考慮すべきこと

どのテストプロセスを自動化するか？（テストマネジメント、設計、テスト生成、テスト実行等）　テスト実行だけが自動化ではない！
どのテストレベルを対象にするか？（コンポーネント、IT、システムテスト等）
どのテストタイプを対象にするか？（機能テスト、適合性テスト、相互運用性テスト　等）
どのテストロールを対象にするか？（テスト実行者、分析、アーキテクト等）
どのソフトウェア、ラインアップ、ファミリーを対象にするか？
どのテスト対象技術を対象にするか？

2. Compare and contrast different design/architecture approaches

テスト自動化エンジニアは各アプローチのpros/consを分析すること。

3. Identify areas where abstraction can deliver benefits

テスト自動化の抽象化は異なるテスト環境等で使われる。キーワード駆動が例の一つである。

抽象化により以下効果が見込まれる

portabilityが増し、vendor中立性を保つ
保守性、新しいテスト対象への適用性が高くなる。
ドキュメンテーションにおいて可読性がよくなる。

抽象化にあたり、機能性、保守性、拡張性を鑑みて、実装レベルのtrade-offを認識する必要がある。
抽象化のinitial costは高くなる傾向だが、長い目で見れば元は取れるはず

4. Understand SUT technologies and how these interconnect with the TAS

テスト対象のI/Fへのアクセスはテスト実行で重要となるものである。
（アクセスレベルはSoftware level,API,Protocol等）
テストエンジニアは、テスト対象とテスト自動化の相互作用の枠組みを決める。２システム（テスト対象と自動化）間でより安全な接合アーキテクチャを考慮する。
paradigmとして以下のようなものを含む

Event-driven paradigm: イベントを通して駆動
Client-server paradigm: 利用者がサービス提供者のシステムを呼び出しすることで駆動
Peer-to-peer paradigm: peer to peerでシステムを呼び出しすることで駆動

5. Understand the SUT environment

テスト対象はstabdalone、systems of systems,hardware等さまざまである。そのため、テスト自動化ではテスト対象の一部をシミュレート/エミュレートする。
テスト環境の例

テスト対象とテスト自動化両方を持つコンピュータ
テスト対象とテスト自動化がネットワークで独立している（server software）
テスト対象のI/Fをシミュレート、監視するテストデバイス (set top box)
テスト対象の操作環境をエミュレートするネットワークテストデバイス
テスト対象のシミュレータ

6. Time and complexity for a given testware architecture implementation

テスト自動化の見積もり例

Analogy-based estimation: Function Point法、3 point 法等
WBS: Work Breakdown Structures で見積もり
Parametric estimation: COCOMO
Size-based estimations: Function Point分析、Story Point等
Group estimations: Planning Pocker

7. Ease of use for a given testware architecture implementation

テスト自動化はいろんな要素を求められる。例えば以下がある

テスター指向設計
使いやすさ
テスト自動化がほかのロールもサポートする
有効性あるドキュメンテーション
実用的レポート
テスト結果フィードバック経験的識見をするための継続的設計

3.2.2 Approaches for Automating Test Cases

テストケースはテスト実行のアクションに変換される。そのアクションが手順、もしくはSCRIPTとしてドキュメント化される。
テスト自動化のテストケースもテストデータを定義し、妥当性確認のSTEPを含む。
いくつかのアプローチがある。プロジェクト次第でアプローチは限られるかもしれない。

テストエンジニアはテストSCRIPTに直接テストケースを実装する。これはあまり勧められない。抽象化してなく、メンテナンスがかかるため。
テストエンジニアはテスト手順を設計し、自動化SCRIPTに変換する。これは抽象化を含んでいるが、テストSCRIPTの自動生成の要素を含んでいない
テストエンジニアはテスト手順をSCRIPTに変換するツールを利用する。これは抽象化、SCRIPTの自動生成の要素を含んでいる
テストエンジニアはモデルからテスト手順作成、テストSCRIPTへの変換するツールを利用する。これは自動化率がかなり高い。

よくある自動化アプローチは以下である

Capture / Playback : approach 1
Structured scripting , Data driven , Keyword driven : approach 2,3
Model based testing : approach 4

UFTやRanorex等自動化ツールは、Capture / PlaybackがベースでStructured scripting, Data driven, keyword drivenの機能も有している。

1. Capture/playback approach

Principal concept

テスト手順に則りテスト対象を操作して操作を記録、操作後のOUTPUTを記録、チェックする。Selenium IDE等が該当する。
チェック方法に、以下のようなレベルがある

Manual: テスターはテスト対象のOUTPUTで異常がないかを監視する必要がある
Complete: captureで記録したOUTPUTを再実施する必要がある
Exact: captureで記録したOUTPUTを詳細レベルで再実施する必要がある
Checkpoints: 選んだOUTPUTのみ、チェックする

1. Interfaces of the SUT

テスト対象は、内外のI/Fをもつ。
テストでは、それらを使用できることが求められる。
合わせて、ログを取れるようにする。

2. SUT data

テストに関係するシステムに関するデータを設定、生成、定義できるようにする。

3. SUT configurations

テスト対象が異なる環境でテストする場合（異なるOSなど）、各環境へのdeploymentを考慮する。

4. SUT standards and legal settings

法的、標準要求を満たすようにする

5. Tools and tool environments used to develop the SUT

開発側のツールとの互換性、トレーサビリティ、アーキテクトの再利用などができるテストツールを検討

6. Test interfaces in the software product

テストのためのI/Fはリリース後も残しておくことが望ましい。
尚セキュリティの観点より、ユーザーからは使えないようにする仕組化が必要。

3.2.4 Considerations for Development/QA Processes

開発、QAのプロセスを考慮するにあたり、以下のようなことがよく議論される。

Test execution control requirements :自動化のレベル
Reporting requirements :テストレポートのフォーマット、文面
Role and access rights :システムへのアクセス権限
Established tool landscape : さまざまな他のツールとの連携

3.3 TAS Development

3.3.1 Introduction to TAS Development

テスト自動化のアクティビティは開発projectと同等である。特化した点は、テスト対象との互換性、同期である。
テスト自動化のSDLC (Software Development LifeCycle)は次の通り。

Analyze
Design
Develop
Test
Deploy
Evolve

テスト自動化のSDLCにbackup, archiving, teardownの工程はない。

3.3.2 Compatibility between the TAS and the SUT

1. Process compatibility

テスト対象のテストと開発は同期すべきである。そして、テスト自動化もしかり。同期が取れて、大きなメリットを得られる。

2. Team compatibility

テスト対象の開発、テスト自動化の開発、双方のチームの両立性も重要である。
相互に要求、設計、開発物に対してのレビューをすることでメリットがある。

3. Technology compatibility

テスト対象の開発、テスト自動化の開発、双方の技術互換性も考慮すべき。双方でシームレスな操作の設計、実装に効果がある。

4. Tool compatibility

テスト対象の開発、テスト自動化の開発、双方のツール互換性も考慮すべき。例えば、マネジメントツールをつかうとき、双方での情報変換が容易になる。

3.3.3 Synchronization between TAS and SUT

1. Synchronization of requirements

テスト自動化の要求仕様は２つにグルーピングできる

テスト自動化の開発のための要求
テスト対象をテストするための要求

これらは、テスト対象、テスト自動化の要求が更新する都度、一貫性を検証し、テスト対象がテストできるように確認することが重要である

2. Synchronization of development phases

テスト自動化がテスト対象をいつでもテストできるように、開発フェーズではお互いに同期する必要がある

3. Synchronization of defect tracking

欠陥はテスト対象、テスト自動化両方に関連する。片方の欠陥を修正すれば、もう一方に影響する

4. Synchronization of SUT and TAS evolution

テスト対象、テスト自動化でどんな変化もお互いに影響を与えるため、このマネジメントが必要になる
双方のSDLCを同期する。
さらにHYBRIDは、マニュアルテストのSDLCとも同期させる

3.3.4 Building Reuse into the TAS

再利用可能なテスト自動化のパーツは以下のようなものがある

テスト目的、テストシナリオ、テストコンポーネント、テストデータのモデル
テストケース、テストデータ、テスト手順、テストライブラリ
テストエンジン、レポートフレームワーク
テスト対象へのアダプターやI/F

再利用の可用性を上げるには以下のようなことがある

テスト自動化アーキテクチャに従い、必要に応じて改定・更新する
テスト自動化のドキュメント化で理解しやすくする
テスト自動化の正確性を確認し、新しい状況での利用をサポートする

再利用を設計で検討することは重要で、SDLCにて保守、改善を考慮すべし。

3.3.5 Support for a Variety of Target Systems

テスト自動化は以下のような異なる設定においてもサポートする

テスト対象コンポーネントの番号、相互接続
テスト対象コンポーネントが稼働する環境
テスト対象実装に使われる技術、プログラム言語等
テスト対象コンポーネントが利用するライブラリ、パッケージ
テスト対象コンポーネント実装につかうツール

技術的相違を取り扱い、テスト自動化のフィーチャー、コンポーネントのマネジメントを可能にする必要がある。

多様なソフトウェアに関してのテスト自動化多様性は別々に取り扱われる

テスト自動化、テスト対象のバージョン管理はそれぞれに合ったバージョン管理をする
テスト自動化のパラメータ化はテスト対象の設定に適合するように使われる

多様性の保守、改善はSDLCを通しての関心事である。継続的な考慮、改定努力、そして変化に対しての選択肢や方式を追加・削除することが求められる