趣旨
ここでは、ISTQBにて提供されている"Test Automation Engineer" Syllabusを自分なりに解釈（そのままの翻訳もあり）したものである
そのため、実際の試験と相違がある場合もありますのでご注意
原本↓
https://www.istqb.org/downloads/category/48-advanced-level-test-automation-engineer-documents.html
1. Introduction and Objectives for Test Automation
1.1 Purpose of Test Automation
テスト自動化がすること
- テスト環境の構築（データ作成等）
- テストの実行
- テスト結果と期待値の比較（Validation）
一番目のテスト環境の構築は有意義。テストデータ、特にSTRESS TESTといった大量のデータを必要とする場合、たとえば１００００予約データを作成するといったものは、自動化で一気に作ったほうが工数削減になる。
テスト自動化の効果
- 多くのテストケースを継続的、繰り返し実行
- さまざまなテスト環境で実施
- 人の操作を介さず実施
テスト自動化のツールに求められる要素
- テスト自動化のテストケースを作成
- テスト自動化の実行の監視、制御
- テスト自動化の結果をレポート
テスト自動化において、実行させるSCRIPTを書くことはエンジニアであればすぐに取っつける。ただ、レポートの機能が後追いになりがち。テストが失敗したときに、どこに問題があったのか等の、その後の対応に適切な情報を提供できる仕組みがないと、テストを実行しているだけのソフトウェアになってしまう。
テスト自動化の目的
- テスト効率改善
- テストカバレッジを上げる
- テストコストを下げる
- パフォーマンステスト
- テスト速度を上げる
- テストサイクルを上げる（例えば 10+ deploys per day)
よくあるのが、テスト自動化のコストを躊躇して導入検討に時間がかかること。
今まで見てきた資料であるのは、３～４回そのテストを実行したら、元が取れるといったもの。
そこにだけフォーカスして導入可否に時間を要するのはもったいないと思う。それ以外の効果、テストフィードバックを大きく改善することを忘れてはいけないと思う。
あるあるの manual vs automation
テスト自動化のメリット
- アプリのbuild毎のテストを増やせる
- マニュアルでできなかったテスト、複雑なテストができる場合がある
- テスト実行が早い、そして結果のフィードバックが早まる
- マニュアルテストのような人手によるミスがなくなる
- リソースの効率化が図れる
- テストの一貫性が上がり、システムの信頼性が上がる
テスト自動化のデメリット
- 追加コストが発生する（初期コストとメンテナンスコスト）
- 自動化の環境構築、スクリプティング等のスキルが要求される
- 本来の自動化の目的を忘れる傾向がある（品質であるはずが、カバレッジが目的になってしまう等）
- テストが複雑になりうる
自動化を継続して使い続けるには、デメリットにもあるように以下のようなメンテナンスをしっかりしていかないと、意味のないものになる。
- 機能変更に追従して回収すること
- エラーが起きた時の対応（放置しない）
- Flaky な自動化スクリプトを放置しない（定期的な、無意味なエラーレポートに悩まされる）
テスト自動化の制約
- すべてのマニュアルテストを自動化できるわけではない
- テスト自動化は機械が理解できることしかチェックできない（スクリプトでvalidateできないものは自動化できない）
- 探索的テストはできない
1.2 Success Factors in Test Automation
テスト自動化の成功要素
Test Automation Architecture
テスト自動化で、どの機能要件、非機能要件をカバーするかを明確にする
保守性、パフォーマンス等を考慮して設計すること
Testability
自動化のscriptingを行いやすくするため、システムはテストしやすい設計が求められる
- GUIでパーツの情報を一意に特定できる
- APIのI/Fを提供する
WEBでは、HTML TAGのclass nameの定義。一意にかつ意味のある名前にすることで、SCRIPTINGでそれを特定しやすくなる
Test Automation Strategy
テスト自動化では以下のことを考慮する
- 保守性、継続性
- コスト
- 利点
- リスク
Test Automation Framework
テスト自動化のフレームワークに求められる要素
- Implement reporting facilities: システムの品質の情報提供
- Enable easy troubleshooting: テスト失敗時の対応のしやすさ（バグ、環境問題 等）
- Address the test environment appropriately: 一貫性のあるテスト環境（不安定な環境では、テストが失敗する）
- Document the automated test cases: テスト目的を明確にする
- Trace the automated test: テストケースの各ステップを理解しやすくする
- Enable easy maintenance: テストscriptの保守性。システム変更に追従しやすくする
- Keep the automated tests up-to-date:もし仕様変更など発生したら、scrpitも更新する
- Plan for deployment:テストscriptのリリースをしやすくする
- Retire tests as needed: 不要になったscriptは廃棄しやすくする
- Monitor and restore the SUT:実環境でテストを実施続け、エラーが起きたら対処する
test scriptのメンテナンス性を高めるために求められる要素
- よく変更の入るI/Fは自動化しない
- 特定のデータに依存、変更の入りやすいデータにかかわる部分は自動化しない
- 変更の入りやすい環境、環境依存な部分を自動化しない
このほかに
- 複雑なテストscriptにしない（テストscriptをテストする？）
- 誰が見てもわかるscript（プログラミングと同じ）
- 一回しか発生しないイベントを自動化しない（復元手段がある場合は別）
- ブラウザ等に依存する機能を自動化しない（クロスブラウザテストをする場合）