趣旨

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

4 Deployment Risks and Contingencies

4.1 Selection of Test Automation Approach and Planning of Deployment/Rollout

テスト自動化の実装、リリースには主な２つの活動がある。パイロットとリリース。

pilot

適切なプロジェクトを識別する
パイロットをプランする
パイロットの実施
パイロットの評価

deployment

最初のプロジェクトを識別する
選んだプロジェクトにテスト自動化を適用する
事前に決めた期間後、監視、評価する
ほかのプロジェクト等に展開する

4.1.1 Pilot Project

ツールの実装は基本的にパイロットから始める。
パイロットの過程にて、予定した効果が得られるかを確かめる。

パイロットの主な目的

テスト自動化に関して詳細を学ぶ
現在のプロセス、ツールのどこに適合するか、どんな変化が起きるかを見極める。
テスターに合った自動化I/Fを設計する
自動化の利用の標準を決める
テスト自動化の利用状況、有用性、保守性、拡張性などをモニタリングするためのメトリックスを決める。
妥当コストで効果があるかを評価する。
どんなスキルが必要で、現在そのスキルを満たしているかどうかを見極める

Identify a suitable project

以下のガイドラインにそってパイロットプロジェクトを選別する

Criticalなプロジェクトは避ける。プロジェクトの遅延等影響を受ける可能性がある
trivialなプロジェクトは避ける。成果があまり見えない。
ステークホルダーを選考プロセスに含める
パイロットのテスト対象は他のプロジェクトにとっての良き参考とすべし

Plan the pilot

パイロットプロジェクトも通常プロジェクトと同様に扱う。
リリース活動に十分なリソースを費やすべきである

Conduct the pilot

実行時に注意する点

テスト自動化期待した機能を提供しているか？
テスト自動化が既存プロセスをサポートしているか？

Evaluate the pilot

すべてのステークホルダーと評価する

4.1.2 Deployment

もしパイロットが成功したと思うなら、ほかの部署等に展開すべきである。
成功の要素は以下の通り

他の組織に展開し、新たなユーザーへのサポートする。これは自動化の拡大することを意味している。考えうるボトルネックは、起きる前に先んじて解決していくこと。
適合するようにプロセスを修正、改善する。
新しいユーザーへのトレーニングを提供する
利用ガイドラインを整備する。FAQなどは質問へのサポートの肥大化を抑える。
実例を集める。どの部分に自動化が使われたかを。
自動化のメリット、コストをモニタリングする。ビジネスへの貢献を可視化する
テストチーム、デプロイチームへの手助けとする
全チームで評価し、学んだことを明示化し、さらに改善につなげる
評価した結果から、改善ステップに進める

4.1.3 Deployment of the TAS Within the Software Lifecycle

自動化の適用は、ソフトウェア開発のフェーズに依存する。
自動化をリリースするのは、コードフリーズやスプリントの終わりといったマイルストーンで実施するのが一般的である。
リリース活動は、時間と労力を必要とするためである。
もし自動化に問題があった場合、リリースはテスト対象と個別で行う必要がある
。

4.2 Risk Assessment and Mitigation Strategies

技術的課題

抽象度の高いものが実際に何をしているのかの理解性を難しくする
データドリブンでデータが肥大化、複雑性を増す
テスト自動化の依存性がすべての対象環境で実行可能ではないときがある

典型的リリースプロジェクトリスク

SCRIPTの保守する人の確保困難性
新しいテスト対象リリースがテスト自動化の不正確な操作を引き起こす
自動化導入の遅れ
テスト対象更新に伴うテスト自動化の更新の遅れ
テスト自動化が非標準オブジェクトをとらえることができない

テスト自動化で失敗しうるとき

異なる環境への移設
対象環境へリリース
開発から新しいリリース

テスト自動化はSLCPがある。テスト自動化はバージョン管理を行い、ドキュメント化するものである。一方、異なる環境でのリリースは困難である。リリース手順もバージョン管理するべし。
テスト自動化のリリースには初回、保守と２種類のリリースがある。

最初のリリースでは、以下のようなステップが必要である

テスト自動化を走らせるインフラを決定
テスト自動化用のインフラ構築
テスト自動化、インフラの保守手順作成
テストスイートの保守手順作成

最初のリリースに伴う想定リスク

テスト実行時間は想定より長くなる。この場合、テストスイートの十分な実行時間確保し、次のテスト実行の前に終わらせる。
初期化、設計の課題。一般的にテスト自動化は必要な前提を構築する効果的な方法を必要とする

保守リリースのため、さらに考慮することがある。

テスト自動化自身進化する必要があり、更新していく必要がある。
更新前にはテストが必要
新機能をチェックし、テストスイート実行か妥当か確認し、レポートが送られ、パフォーマンスに問題がないことを確認する

保守リリースの時、以下ステップが必要となる

新旧で差分を評価する
テスト自動化の新機能、既存機能（リグレッション）をテストする
テストスイートが新バージョンで適合するかを確認する

テスト自動化の更新には以下のようなリスクをはらむ

テストスイートを更新する必要がある
テストハーネス（スタブ、ドライバ）を修正する必要がある。
インフラを更新する必要がある。
新たな不具合、パフォーマンス問題を生む。

4.3 Test Automation Maintenance

テスト自動化はモジュール化、拡張性、理解性、信頼性、テスタビリティが必要である。
内部変更や環境変更においても、保守が必要である。
テスト自動化を保守する（新しいソフト環境に追従したり、新しい法律等に従う）ことは、信頼性と安全性を確保し、ライフスパンやパフォーマンスを最適化する。

4.3.1 Types of Maintenance

システムの修正、移行、撤退の過程でテスト自動化の保守が行われる。このプロセスは以下のようなカテゴリに分類される

Preventive maintenance : テスト自動化がもっとテストタイプをサポートし、いろいろなI/F、バージョンでテストするように変更する
Corrective maintenance : テスト自動化の欠陥を修正するための変更。保守の良い方法は、標準的な保守テストの実行である
Perfective maintenance : 最適化、非機能課題を解決。パフォーマンスやユーザビリティ、耐久性、保守性を目的とする
Adaptive maintenance : 新法の適合、標準、産業の要求などに対応させる

4.3.2 Scope and Approach

保守のスコープは以下のような要素に依存する

テスト自動化の規模、複雑性
変更規模
変更によるリスク

変更によりシステムがどう影響を受けるかを分析する必要がある。
影響次第で、変更を増やしながら加え、テストを実施する。

時間効率がテスト自動化で求められているため、以下のようなベストプラクティスを持つことが重要である

テスト自動化のリリース手順、利用方法をクリアにしドキュメント化する
サードパーティの依存をドキュメント化する
テスト自動化をモジュール化し、部分的置き換えを可能にする
テスト自動化が変更可能な環境で動く
テスト自動化がテスト自動化フレームワークとスクリプトを切り離す
テスト自動化が開発環境と独立している
環境、テストスイート、テストウェアを含んだテスト自動化は設定管理下に置く

サードパーティやライブラリの保守で考慮することは以下の通り

テスト自動化はサードパーティ、ライブラリに依存する傾向である。これらをドキュメント化し、設定管理下に置く
これら外部コンポーネントを修正するプラン（フロー）を確立しておく。コンタクトパーソンを明確にするなど
ライセンスに関する情報のドキュメント化
サードパーティの更新情報の入手経路を明確にする

ネーミングルール等を以下のように考慮する

ネーミングルールや他規則は簡単な理由を持つ。可読性・理解性・変更維持性を持たせる。維持などの時間を最小限にする
新しい人への導入を簡単にする
ネーミング規則は変数、ファイル、テストシナリオ、キーワード、パラメータなどに及ぶ。他規則はテストの前もって必須事項や事後処理、テストデータ環境、実行環境、ログ、レポートに及ぶ
すべての基準は同意を得て実施する

ドキュメントに関して考慮すべきことは以下の通り

テストシナリオ、テスト自動化双方のドキュメント化はクリアにすべきだが、課題がある。書くこと、保守すること。
テストツールのコードはセルフドキュメント化、セミ自動化である一方、サードパーティのすべてのデザイン、コンポーネント、依存関係、リリース手順などはだれかがドキュメント化する必要がある
開発プロセスの一部として、ドキュメント化を導入することはよい実施例である。ドキュメント化されてない場合、タスクが完了したとみなさないことである

トレーニングに関して考慮すべきこと

テスト自動化に関してのドキュメントはよくなされていれば、トレーニングのベースになる
トレーニングマテリアルはテスト自動化の機能的仕様、デザイン、アーキテクチャ、保守、利用方法、実例、チップスなどの組み合わせである
トレーニングマテリアルの保守は書くことと、レビューすることが基本である。実際に、チームメンバーがトレーナーとして働くことでなされる。