趣旨
ここでは、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のみ、チェックする
Pros
GUI, APIレベルのテストに使える。setupや使い方は簡単
Cons
SCRIPTの保守は困難。なぜなら、captureしたときのシステムversionに大きく依存するため。GUIの変更が発生した場合、SCRIPTが無効になる場合がある
また、テスト対象が稼働してからでないと、SCRIPTすることができない。
2. Linear scripting
Principal concept
scriptingはいくつかのマニュアルテスト手順から始める。
その間、OUTPUTを記録する。一般的に、その操作結果が一つのSCRIPTになる。そのSCRIPTに可読性を上げ、チェックポイントを追加する。
この操作を繰り返す。
これは、大規模なテスト、多くのリリースを行う環境ではあまりよくない。保守コストが大きくなる
Pros
事前に準備が必要としない。
単純にマニュアルテスト操作を記録・再生する。
プログラミングスキルを必要としないが、あると有効。
Cons
実行のSTEP数だけ、自動化の労力が必要となる。
似たテスト手順がある場合、最初の手順と同様なSCRIPTになる。（類似SCRIPTが散在することになる）
SCRIPTはプログラム言語なので、非プログラマにとって理解が困難で時間がかかる。
SCRIPTにはコメントを含む。このコメントはSCRIPTの保守に有効だが、肥大化していく。
3. Structured scripting
Principal concept
Linear scriptingとの違いは、libraryの存在である。
共通機能のlibraryを再利用する
Pros
仕様変更に対する保守コストが大幅に減らせる。
共通鵜機能の活用で、場合によって新規テストのコストも減らせる。
Cons
初期コストがかかる。
プログラミングスキルが求められる
4. Data-driven testing
Principal concept
テストのインプットとSCRIPTを分離させる。
インプットを複数用意し、このSCRIPTを再利用する。
データに応じた制御が一部発生するが、全パターンを個々でSCRIPTするよりははるかに効率が良い
Pros
様々なバリエーションテストにおいて、大幅にテストコストを減らせる。
テストアナリストは、インプットのデータに特化してテストを考えることができるので、ロールの分担ができる
Cons
テストデータの管理が発生。
ネガティブテストケースは失敗する可能性がある
※ここでなぜ失敗するのかの理由が書いてない。失敗のパターンもSCRIPTINGで組むことはできると、個人的に思う
5. Keyword-driven testing
Principal concept
test definition file : テストアナリストが理解できるテスト定義のデータ（キーワード）を利用する
このキーワードを使ってテストを定義する。high levelなテストになる。
各キーワードにSCRIPT（テスト処理）が隠蔽されている。
※例） ログイン → 購入 → 完了
Pros
キーワード操作の工数はとても少なくなる。
テストの定義が理解しやすくなる。
テストアナリストは特別なスキルがなくてもテストシナリオを定義できる。
テストケースの保守が簡単になり、複雑な処理はキーワードに隠蔽される。
Cons
キーワードに隠蔽された処理をSCRIPTするコストは大きい。
6. Process-driven scripting
Principal concept
keyword-drivenをベースにしている。違いとして、テストシナリオはテストデータでパラメータ化された、もしくはhigh levelなテスト定義によって構成されている点である
Pros
テストケースがワークフローにあわせて定義できる。
かなりHigh Levelな定義になる
Cons
テスト対象のプロセスを理解するのが簡単ではなくなる
7. Model-based testing
Principal concept
Scriptingから抽象化したモデルを使い自動化する。
Pros
テストの本質に集中できる。
Cons
モデリングの専門知識が求められる。
※モデルベーステスティングを実務でやったことがないので、概念がわかるが実際にどうなのかがイメージが個人的にわからない。
3.2.3 Technical considerations of the SUT
技術面から考慮しないといけないこと。
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を通しての関心事である。継続的な考慮、改定努力、そして変化に対しての選択肢や方式を追加・削除することが求められる