趣旨

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

8 Continuous Improvement

8.1 Options for Improving Test Automation

テスト自動化をテスト対象と同期続けるための保守タスクに加え、改善の機会もある。テスト自動化改善はさらに大きな効果、使いやすさ、可用性、テストアクティビティの改善になる。テスト自動化をどのように改善するかは、プロジェクトに付加されるメリットに影響する。
いろいろな分野の改善余地がある

Scripting

scriptingでは、シンプル構造アプローチからデータドリブンに変化し、洗練されたキーワード駆動にする。現在のテスト自動化をupgradeするのに適切である。
スクリプトアプローチの変更だけではなく、改善はscriptingの実装にもフォーカスする
例）

• 自動化を統合するため、テストケース、ステップ、手順の重複を評価する。類似のテストケースは何回も実装しない。再利用を考慮したライブラリ化を検討する。これにより保守性が上がる。（キーワード駆動でよくある）
• エラー復旧性を持たせる。エラーが起きたとき、エラー状態から復旧し、次のステップのテストを実施させるようにする。
• ウェイト機構を考慮する。３パターン
  • ハードコードウェイトは多くの自動化の問題を引き起こしうる
  • 動的ウェイト　ポーリング等のような。適切なウェイトになるため、無駄なテスト実施時間になることはないが、タイムアウトを考慮しないと、問題があったとき、ずっと待たされる場合がある
  • イベント機構。これは上記２つより信頼性があるが、テストスクリプトはサブスクリプション機能をサポートする必要がある。
• テストウェアとソフトウェアとして扱う。テストウェアの開発・保守はソフトウェア開発と同じである。
• 既存scriptの改定、削除の評価。いくつかのscriptは問題があり、再設計が望ましい時がある

Test Execution

テストに時間がとてもかかる場合

• 同時に別環境で実施を考慮する必要があるが、高価なシステムを扱っているような、ひとつしかテスト実施環境がないかもしれない。
• テストをいくつかに分割することを考慮する
• テスト自動化のカバレッジが重複しているかもしれないので、それを取り除く

Verification

新しい検証機能を作る前に、検証方法の基準を適応する。これにより、再実装を割けることができるかもしれない。検証方法が似てる場合、パラメータ化が役立つかもしれない。

Architecture

テスタビリティを改善するとき、アーキテクチャを変更する必要があるかもしれない。テスト対象、自動化両方で変更を考慮する必要がありうる。これにより大きな改善があるが、大きな変更が求められうる。例えば、テスト対象のAPIを変更したら、自動化もそれに合わせて改修が発生。これが後工程で起これば、改修コストは高くなる。自動化の検討時に考慮すべきである。

Pre- and post-processing

標準的なセットアップ（事前設定）、解体（事後処理）を提供する。これにより、このステップの繰り返しの実装のタスクを抑え、保守コスト、新しい自動化実装時の労力を減らす

Documentation

スクリプト、自動化マニュアル、レポート、ログに関するドキュメントを提供する

TAS features

テスト自動化の付加機能、詳細なレポート、ログ、他のシステムへの統合などを追加する。必要に応じて追加する。

TAS updates and upgrades

自動化の更新、アップグレードにより、新しい機能は有効になり、テストケースに利用される。リスクは更新により既存機能へネガティブ影響を起こすかもしれない。リリースする前に、新機能をテストする。

8.2 Planning the Implementation of Test Automation Improvement

既存の自動化テストの変更は注意深くプラン、調査が求められる。些細な変更でも全体に及ぼし、信頼性、パフォーマンスに影響しうる

Identify changes in the test environment components

変更、改善個所を評価する。テスト自動化のパフォーマンスに影響する。テスト自動化の目的は、継続して効果的に走らせることである。変更は徐々に行うべきで、実施の中で影響を測定する。問題がないことが確認できれば、変更を完全に実装する。すべてのリグレッション実施は最後に行い、変更がテスト自動化に影響がないことを検証する。実行中にエラーが見つかるかもしれないが、根本原因を認識し、自動化の改善によるものではないかを確認する。

Increase efficiency and effectiveness of core TAS function libraries

テスト自動化が成熟するにつれ、効果的にタスクを実施する新しい方法が見つかる。新しい方法はコアファンクションライブラリに組み込む必要がある

Target multiple functions that act on the same control type for consolidation

テスト自動化で起きる大部分は、GUIへの問い合わせである。これは制御にかんする情報を提供する。この情報でテスト自動化がドロップダウンリストから選択し、フィールドにデータを入力、読み出し、等ができる。情報を引き出す制御をする。

Refactor the TAA to accommodate changes in the SUT

テスト自動化は、テスト対象の変更に追従する必要がある。テスト対象が進展、成熟につれ、テストアーキテクチャも進展し、テスト対象をサポートすることを確保する。テスト対象の新しい機能が追加のスクリプトを必要としたとき、互換性コンポーネントが新しいテスト自動化を追従するために置かれる

Naming conventions and standardization

自動化コードの命名規則は事前に定義した基準に沿う必要がある

Evaluation of existing scripts for SUT revision/elimination

変更、改善プロセスは既存SCRIPTの評価、利用価値、継続価値を含む。例えば、あるテストが複雑で実行に時間がかかる場合、それをいくつかの小さなテストに分解することが、価値があり、効果的になる可能性がある。まれに実施するターゲティングテストは複雑性を排除し、よりよい透明性をもたらす