趣旨
ここでは、ISTQBにて提供されている"Test Automation Engineer" Syllabusを自分なりに解釈（そのままの翻訳もあり）したものである
そのため、実際の試験と相違がある場合もありますのでご注意
原本↓
https://www.istqb.org/downloads/category/48-advanced-level-test-automation-engineer-documents.html
2. Preparing for Test Automation
2.1 SUT Factors Influencing Test Automation
テスト自動化に影響する要素
- SUT interfaces : システムを動かすとき、UIやI/Fなど様々なlayerを経由して行われる。そのlayerのlevelに合わせたテスト自動化が選択される
- Third party software : システムは3rd partyを含むときがある。それもテストが求められる
- Levels of intrusion : テストlevelに応じてテスト自動化アプローチは異なる
- Different SUT architectures : システムのarchitecture（例えば開発言語）次第でテスト自動化が変わってくる
- Size and complexity of the SUT : システムの複雑さでテスト自動化の構成を考える
- SUT not available, but can start : テストscriptingはSUTが出来上がらなくても、設計があれば始めることは可能。
コードのwhite-boxテストするときはUnit Test、UIのWhite-boxテストするときは、E2E Testといった開発レイヤーにあったツールを選ぶということでしょう。
2.2 Tool Evaluation and Selection
TAE(Test Automation Engineer)は以下を留意して自動化ツールの評価・選定を行う
- 組織の成熟度とテストツールの導入機会を評価する
- テストツールの目的を評価する
- 適切なツールの情報収集
- ツールを分析
- コストメリットを分析
- ツールの選定
- システムの互換性を確認する
個人的には、メンバーのスキルセット（プログラマーのスキル有無）、コードの保守性（可視性、改修容易性）、ツールの保守性（バージョンアップのサポート）等に重点を置いた。
iOSやAndroidではOSのversion upが定期的に発生する。これに追従してくれるツールを事前に確認するとよい。
ツールでよく遭遇する課題
- ツールのI/F変更で連携が失敗する
- 依存ソフトウェア(Java等)の更新により動かなくなる
- オブジェクトを識別しない（ツールが要件を満たさない）
- ツールの機能が多すぎて複雑
- ほかのシステムと依存があり動かなくなる
- 自動化の有無でシステムの挙動が異なる
- 自動化のためにソース変更が発生する
- テスト環境のリソース（メモリ等）が不足する（本番と異なる）
- システムの更新でこれまでの環境が使えなくなる
- セキュリティの制約でテスト環境にアクセスできない
- 環境によってテストが動かない
モバイルのアプリは独自SDKをインストールしないと自動化が動かないといった経験があった。アプリのオブジェクト抽出が難しいのでしょう
2.3 Design for Testability and Automation
自動化に限ったことではないが、システムに安定したテスト自動化が行われるようにteatabilityを持つ必要がある
- Observability: システムの状態を正しく確認できるようなI/Fを持つ。機械が判断できる値、API等を提供しないと、自動化は合否判定できない
- Control(ability): システム操作するために適切なI/Fを用意する（上位層ではスイッチ等、中間層ではTCP/IP等のプロトコル）
- Clearly defined architecture: 上記I/Fがわかりやすく、判別しやすいものとする
テスト自動化のscriptは対象オブジェクトを一意に識別し、操作後それが正しいかを機械的に判断することができる判断軸があることが求められる。テスト結果が正しいかを判断するのが機械なので、機械が判断できるものをシステムが提供する必要がある。
上記をみたす例
- スタブなどの提供
- 故障モードを提供する
- 代替I/Fでテストが可能
- 状態遷移テストはカスタマイズしたI/Fを利用して再現する
testabilityを考慮することは、自動化だけでなく、マニュアルテストにも当然効果がある。