趣旨
ここでは、ISTQBにて提供されている"Test Automation Engineer" Syllabusを自分なりに解釈（そのままの翻訳もあり）したものである
そのため、実際の試験と相違がある場合もありますのでご注意
原本↓
https://www.istqb.org/downloads/category/48-advanced-level-test-automation-engineer-documents.html
6 Transitioning Manual Testing to an Automated environment
6.1 Criteria for Automation
以前はマニュアルテストケースを作成してきたが、自動化環境作成にシフトしてきている。マニュアルテストの構造は自動化に適したり、適さないかもしれない。自動化のためにマニュアルテストケースの書き直しは必要かもしれない。関連する既存のマニュアルテストのコンポーネントはマニュアルテストから抽出され、自動化に再利用されるかもしれない。
すべてのテストが自動化できるわけではなく、最初はマニュアルになるかもしれない。そのため、２つの側面にわけられる。初回の既存マニュアルから自動化への変換と、それ以降の新しいマニュアルテストから自動化への変換。
テスト自動化でユーザーIFのないシステムの自動化も可能である。この場合、統合テストレベルで実施される。これらのテストケースはマニュアルで実行される一方、実用的ではない。例えば、自動化でメッセージキューにメッセージを入れることは可能である。この方法で、マニュアルテストがまだ可能ではなくとも始められる。
テスト自動化開始に先立ち、自動化構築とマニュアルテストとでの妥当性、実用可能性を考慮する必要がある。適切なクライテリアは以下のようなものを含む
- 利用頻度
- 自動化の複雑さ
- ツールサポートの互換性
- テストプロセスの成熟度
- ソフトウェアライフサイクルのステージで自動化の適合性
- 自動化環境の持続可能性
- テスト対象の制御可能性
Frequency of use
どの頻度テスト実行が必要であるかが、自動化すべきかの可能性を考える要素の一つである。
定期的なテスト実行は、自動化を考慮するにあたっての良い理由である。アプリのリリース頻度が増えるにつれて、テスト自動化のメリットは増える。機能テストは自動化され、続けてのリリースにリグレッションテストとして使われる。
テストスクリプトが１年に１回走らせるとするならば、テスト対象は１年のうちに代わるかもしれない。この場合、テスト自動化を作成するのは現実的ではない。
Complexity to automate
複雑なシステムをテストするとき、テスト自動化で大きな恩恵を得る。マニュアルテストの複雑なステップの繰り返しテスト、その労力などを減らす
しかし、実際のテストスクリプトは難しく、自動化にするコスト効果はそこまでではない。
Compatibility and tool support
テストツールには、商用ベンダー製、OSSなどがある。
テストツールの相互互換性の問題は過小評価されるべきではない。ツールとテスト対象との互換性を理解せずには、プロジェクトはうまくいかない。
Maturity of test process
テストプロセスにおいて、自動化を効果的に実装するために、プロセスを構築し、訓練、繰り返し実施する必要がある。
Suitability of automation for the stage of the software product lifecycle
テスト対象はライフサイクルを持っている。システムは変更、拡張していくものである。
初期フェーズでは、自動化テストのスクリプト実装の変化は速い。
レイアウトの最適化等では、自動化作成は継続的な作業を求められる。
大規模システムで、システムが安定し、コアな機能を持っているとき、テスト自動化実装には最適なタイミングとなる
システムが、EOLを迎えるとテスト自動化はお勧めできない。しかし、別のアーキテクチャで再設計し、既存機能を使い続けるなら、テスト自動化は意味がある。
Sustainability of the environment
テスト環境は柔軟性があり、変更に適応性が求められる。これは、速やかに診断し、問題を修正する能力である。
Controllability of the SUT (preconditions, setup and stability)
自動化エンジニアはテスト対象の制御と可視化をし、効果的な自動化の手助けとする。一方、テスト自動化はUI相互操作に依存し、結果として保守性が低くなる
Technical planning in support of ROI analysis
テスト自動化はテストチームに様々な度合いの利益をもたらす。
しかし、おおきなレベルの労力とコストも実装に求められる。時間と労力を浪費するに先立ち、評価を行うべきで、どんな効果が得られるかを評価する。ROIを考える必要がる
以下のようなことを対処する必要がある
- テスト環境において、ツールの利用可能性
- テストデータ、ケースの正確性
- テスト自動化の効果のスコープ
- テストチームの教育
- ロール＆レスポンシビリティ
- 開発とテストエンジニアの協業
- 並行作業
- テスト自動化のレポート
Availability of tools in the test environment for test automation
ツールはテスト環境にインストールされ、正しく動くことを確認しておく必要がある。これはツールの定期的な更新も含む
Correctness of test data and test cases
マニュアルテストデータ、ケースの正確性、完全性は自動化において重要である
Scope of the test automation effort
自動化で素早い成功を示し、進捗に影響のある課題のフィードバックをするために、限られたスコープから始めることは将来の自動化タスクを簡単にする。このパイロットプロジェクトはシステム全体の代表的な関数をスコープにする。パイロットから学ぶことは将来の時間見積もり、スケジュール調整に役立ち、求められる技術が明確になる。
パイロット選定において、自動化対象のテストケースの選定は賢明にする。少しの工数で大きな成果を見出すものを選ぶ。リグレッションやスモークテストは実装され、付加価値を生む。他の例として、信頼性テストがある。これは何度も実施するものである。
優先度決めも重要。パイロットで技術的に困難なものを自動化するのは避けたほうが良い。また、おおきな工数がかかるのに小さい効果しか得られないものもである。
Education of test team to paradigm shift
テストにおいて、いろんなバックグラウンドの人がいることが望ましい。チームが自動化にシフトすることは専門的になることである。育成はチームの不安をとりのぞく。
Roles and responsibilities
テスト自動化にみんながアクティブに参加すべきだが、全員が同じロールではない。自動化には設計、実装、保守がある。適切なSCRIPTを実装するために、ドメイン知識、テストスキルをもった人たちが必要である。ドメイン知識は、サービスの機能のカバレッジを確認し、テストスキルは自動化環境の構築、実装に求められる。
Cooperation between developers and test automation engineers
開発者とテスターは密接に自動化を取り組む必要があり、開発者はテクニカル情報を提供できる。テスト自動化エンジニアはテスタビリティの課題も取り上げる
Parallel effort
多くの組織は、並行チームで既存のマニュアルテストを自動化する。テストスクリプトがマニュアルテストに取って代わられる。しかしそれに先立ち、自動化とマニュアルで比較、検証される
この評価によって、自動化への置き換えが決定される
Automation reporting
自動化のレポートは失敗、成功の情報、パフォーマンス等を示している。これは重要なレポートになる
6.2 Identify Steps Needed to Implement Automation within Regression Testing
リグレッションテストはテスト自動化で大きな効果を発揮する
リグレッションを検討するにあたり、以下のような質問がくる
- テストはどの頻度で実施されるか？
- テストスイートの実行時間は？
- テストで重複しているところがないか？
- テストでデータを共有するか？
- テストはお互いに依存するか？
- テスト実行前に事前条件があるか？
- テストカバレッジは？
- 失敗なしでテスト実行するか？
- リグレッションテストが長い場合、どうすべきか？
これらの詳細を以降追っていく
Frequency of test execution
定期的なリグレッションテストを実施するのは自動化はいい選択肢である。実行時間も減らすことができる
Test execution time
テスト実行にかかる時間は自動化の実装の評価への重要なパラメータである
時間のかかるテストにおいて、テスト自動化は一つの選択肢となる。
すばやく、かつ効率的にテストをすることができ、頻度高くテストのフィードバックを受けられる
Functional overlap
既存のリグレッションテストの自動化を行うとき、テストケースと自動化で重なる機能を確認することはいい実行例である。これにより効果的にテストが行える。いくつかのマニュアルテストを一つの大きな自動化テストにすることも一つのソリューション
Data sharing
異なるテスト対象で実行すための同じ結果をだすためのデータを使う場合、データの共有が発生する。例えば実行シナリオは異なるが、同じ権限・条件のユーザーを使う場合が該当する。マニュアルでは、同じユーザが重複して何度も作られるが、自動化ではそれを共有する
Test interdependency
複雑なリグレッションを行うとき、一つのテストはほかのテストと依存を持つことがある。これはよく起きることである。
例として、テストステップで新しいorder IDが作られるシステムをみる。
連続したテストでは、以下のことが検証にて望まれる
a. 新しいorderが正しく表示される
b. order変更を可能にする
c. order削除を成功する
この場合、最初のテストでorder idは動的に作られ、のちのテストで再利用される。テスト自動化ではこの観点を処理に含む。
Test preconditions
初期状態より前でテストはしばしば失敗する。この状況では、正しいデータベースが選ばれたり、パラメータ設定を含んでいる。
テスト実行前にこのステップを見逃さなければ、信頼性のあるソリューションになる。リグレッションテストは自動化され、事前条件は一つの重要なプロセスである
SUT coverage
テスト対象の品質を確認するため、テストは幅広く、かつ深く実施されるように設計する。加えて、コードカバレッジツールがその測定に使われる。測定することがテスト自身の品質の測定に使われる
Executable tests
マニュアルから自動化テストにする前に、マニュアルテストが正しいことを確認するのは重要である。
マニュアルテストが正しくない場合、無駄な自動化が出来上がる
Large regression test sets
リグレッションテストが大きくなりがちである。そのため、一夜でテストがやりきれない場合がある。この場合、もしマルチテスト対象が可能なら同時実行を考える。乏しいテスト対象の場合は、実行対象を絞る。
6.3 Factors to Consider when Implementing Automation within New Feature Testing
新機能が導入されると、テスターはそれに関して改めて新しいテストを実装することが求められる。テストエンジニアはドメイン知識のある設計者から新機能を満たしているかどうかフィードバックを得る。
新機能が実装されるとき、テストウェアを更新する必要がある。加えてツール互換性を評価する。新環境で動くことも評価する。
新しいテスト要求は既存自動化にも影響しうる。そのため、変更する前に、既存が動くことを確認する。
要求のトレーサビリティも更新する
最終的に、テスト自動化は現在のテスト対象のニーズに合わせ続ける必要がある。
6.4 Factors to Consider when Implementing Automation of Confirmation Testing
バグがみつかり、改修されたとき、その欠陥が存在しないことを確認が行われる。
欠陥は継続的なリリースにおいて再び埋め込まれるものである。そのため、それを行うのが自動化である。
自動化は狭い範囲の機能をスコープとしている。欠陥がレポートされると実装が起きる可能性がある。自動化された確認テストは標準のリグレッションテストに組み込まれる。
確認テストを追っかけることは、欠陥解決にかかる時間、テストサイクル等の追加のレポーティングになる。
確認テストに加えて、リグレッションテストはバグがないことを確認するのに必須である。