ISTQB Test Automation Engineerを訳してまとめてみた

　ISTQB Test Automation Engineerのシラバスを読んで、要点を抜粋しながらまとめてみました。

　訳しながらだったので読み終わるまでに時間がかかりましたが、自動テスト初心者の私にはこうやってテスト自動化進めていけば良いのかと知れて、すごく為になりました。

シラバスの原文はこちら↓

https://www.istqb.org/certification-path-root/test-automation-engineer.html

用語

用語	意味
TAS	テスト自動化ソリューション（Test Automation Solution）
SUT	テスト対象のシステム（system under test ）
TAA	テスト自動化アーキテクチャ（Test Automation Architecture）
TAF	テスト自動化フレームワーク（Test Automation Framework）
gTAA	一般的なテスト自動化アーキテクチャ（Generic Test Automation Architecture）

1. テスト自動化の概要と目的

テスト自動化の目的

テスト効率の向上
より広い機能範囲の提供
総テストコストの削減
手動でできないテストの実行
テスト実行期間の短縮
テスト頻度の増加/テストサイクルに必要な時間の削減

テスト自動化のメリット

時間または労力の節約
→ テスト作業が軽減され、他の種類の手動テスト（探索的テストなど）に充てることができる
実行されるテストの量の増加（カバレッジの幅または深さ、または実行頻度）
再現性の向上
手動エラーの減少
手動でできないテストができる(リアルタイム、リモート、並列テスト)
より効果的で効率的なテストリソースの使用
ソフトウェアの品質に関する迅速なフィードバック
テストの一貫性の向上

テスト自動化のデメリット

追加費用が含まれる
TASをセットアップするための初期投資
チームに開発および自動化のスキルが必要
継続的なTASメンテナンス要件
テストの目的をそらすことができる(例：テストの実行を犠牲にしてテストケースの自動化に焦点を合わせる)
テストがより複雑になる可能性がある
自動化によって追加のエラーが発生する可能性がある

テスト自動化の成功要因

　テスト自動化の主な成功要因は次のとおりである。これらは稼働中のテスト自動化プロジェクトに適用されるため、プロジェクトの長期的な成功に影響を与える。

テスト自動化アーキテクチャ(TAA)
SUTのテスト容易性
テスト自動化戦略
- 自動化戦略を作成するときは、コードのさまざまな部分に適用することのコスト、利点、およびリスクを考慮する
テスト自動化フレームワーク(TAF)
- テスト自動化コードは、保守が複雑になる場合がある
- インターフェイスに依存するコードを作成しない
- データ変更の影響を受けやすい、または特定のデータ値への依存度が高いテスト自動化を作成しない

　テスト自動化プロジェクトを開始する前に、選択したアプローチのリスクとプロジェクトのコンテキストを念頭に置いて、適切な要因と不足している要因を検討することにより、プロジェクトが成功する可能性を分析することが重要である。

2. テスト自動化の準備

テスト自動化に影響するSUT要因

　SUTとその環境のコンテキストを評価するとき、適切なソリューションを決定するために、テストの自動化に影響を与える要因を特定する必要がある。これらには次のものが含まれる。

SUTインターフェース
サードパーティソフトウェア
干渉レベル
様々なSUTアーキテクチャ
SUTのサイズと複雑さ

　これらの要因のいくつかはSUTがすでに利用可能である場合に既知であるが、ほとんどの場合、SUTが利用可能になる前にテスト自動化を開発する必要がある。
　SUTがまだ存在しない場合にテスト自動化計画を開始できる例として、次のものがある。

要件（機能的または非機能的）がわかっている場合 →自動化の候補をそれらの要件から選択し、それらをテストする手段を特定
アーキテクチャと技術設計が開発されているとき →テストをサポートするソフトウェアインターフェイスの設計を行う

テスト容易性と自動化のための設計

　SUTのテスト容易性（例：SUTの制御と監視を可能にするためのテストをサポートするソフトウェアインターフェイスの可用性）は、SUTの他の機能の設計と実装と並行して設計および実装する必要がある。テスト容易性の設計は次のような部分で構成されている。

可観測性
コントロール
明確にされたアーキテクチャ

　自動化の設計では次のことに考慮する。

既存のテストツールとの互換性を早期に確立する必要がある
テストツールの互換性は、重要な昨日のテスト自動化機能に影響を与える可能性がある
ソリューションでは、プログラムコードの開発とAPIの呼び出しが必要になる場合がある

　テスト容易性の設計は優れたテスト自動化アプローチにとって最も重要であり、手動テストの実行にもメリットがある。

3. 一般的なテスト自動化アーキテクチャ(gTAA)

gTAAの概要

　gTAAは次の水平層に構造化される。

Test generation (テストの生成)
　テストケースの手動または自動設計をサポートする層。テストケースを設計する手段を提供する。
Test definition (テスト定義)
　テストスイートやテストケースの定義と実装をサポートする層。テスト定義をSUTやテストシステムテクノロジーやツールから分離する。
Test execution (テストの実行)
　テストケースとテストログの実行をサポートする層。選択したテストを自動的に実行するテスト実行ツールと、ログおよびレポートを提供する。
Test adaptation (テストの適応)
　SUTの様々なコンポーネントまたはインターフェースに自動テストを適応させるために必要なコードを提供する層。API、プロトコル、サービスなどを介してSUTに接続するための様々なアダプターを提供する。

TASは、テスト環境（およびそのアーティファクト）とテストスイート（テストデータを含むテストケースのセット）の両方で構成される
gTAAは、構造化、オブジェクト指向、サービス指向、モデル駆動などのソフトウェアエンジニアリングアプローチ、およびソフトウェアテクノロジーとツールによって実装できる
テスト自動化プロジェクトは、ソフトウェア開発プロジェクトとして理解、設定、管理する必要があり、専用のプロジェクト管理が必要

テスト自動化アプローチの要件

テストプロセスのどのアクティビティまたはフェーズを自動化するか
サポートする必要があるテストレベル（コンポーネントレベル、統合レベル、システムレベルなど）
サポートする必要があるテストの種類（機能テスト、適合性テスト、相互運用性テストなど）
サポートする必要があるテストロール（テスト実施者、テストアナリスト、テストアーキテクト、テストマネージャーなど）
どのソフトウェア製品、ソフトウェア製品ライン、ソフトウェア製品ファミリをサポートするか（例：実装されたTASのスパンと寿命を定義するため）
SUTテクノロジーとの互換性を考慮してTASを定義するなど、どのSUTテクノロジーをサポートするか

　TASの開発は、他のソフトウェアの開発プロジェクトに匹敵する。TASの互換性とSUTとの同期は、TAAの設計およびTAS開発で考慮する必要がある。また、SUTはテスト戦略の影響を受ける。

　SUTとTASの2つのSDLCプロセスは主に2つのフェーズで同期されること次の図は示している。

　① TAS分析はSUT設計に基づいている。
　② SUTテストはデプロイされたTASを利用する。

TASとSUTの互換性

プロセスの互換性：SUTのテストは、その開発と同期する必要がある。テストの自動化の場合は、TAS開発と同期する必要がある。
チームの互換性：TASとSUT開発の両チームは、互いの要件、設計または開発成果物を確認し、問題について話し合い、互換性のあるソリューションを見つけることで利益がある。
テクノロジーの互換性：TASとSUT間のシームレスな相互作用を最初から設計および実装すると有益である。
ツールの互換性：TASとSUTの管理、開発および品質保証の間のツールの互換性を考慮する必要がある。例えば、要件管理や問題管理に同じツールを使用すると、情報の交換やTASとSUTの開発の調整が容易になる。

TASとSUT間の同期

要件の同期：SUTまたはTAS要件が更新された場合は常に、2つの間の整合性を検証し、TASによってテストされるすべてのSUT要件にテスト要件が定義されていることを確認することが重要である。
開発フェーズの同期：SUTのテストにTASが必要な時、SUTとTASの開発フェーズが同期していると効率的である。
欠陥追跡の同期：2つのプロジェクト間の関係により、1つのプロジェクト内で欠陥が修正されると、他のプロジェクトに影響を与える可能性がある。欠陥追跡と確認テストはTASとSUTの両方に対処する必要がある。
SUTとTASの改良の同期：SUTとTASの両方が改良して、新機能を追加したり、機能を無効にしたり、不具合を修正したり、環境の変更に対応したりする。SUTまたはTASに適用された変更は他にも影響を与える可能性があるため、SATとTASの両方に対応する変更管理を行う必要がある。

4. デプロイのリスクと不測の事態

　TASの実装とロールアウトには、パイロットとデプロイという2つの主要なアクティビティがある。

パイロットプロジェクト

目的

TASを使用して計画された利点を確実に実現できるようにすること

計画

パイロットは定期的な開発プロジェクトとして扱う
計画を立て予算とリソースを予約し、進捗状況を報告し、マイルストーンを定義する

実施時に注意する点

TASが期待通りの機能を提供するか
TASと既存のプロジェクトがお互いをサポートしているか

デプロイ

　パイロットが評価され、成功したと見なされた場合に、デプロイする。デプロイでは次の手順を検討する必要がある。

最初のターゲットプロジェクトを特定する
選択したプロジェクトにTASをデプロイする
事前定義された期間の経過後、プロジェクトのTASを監視および評価し、残りの組織/プロジェクトにデプロイする

　ロールアウトは段階的に行われ、適切に管理されている必要がある。導入の成功要因は次のとおりである。

段階的なデプロイ
TASの使用に適合するようにプロセスを適応および改善する
新しいユーザーにトレーニングとコーチング/メンタリングを提供する
使用ガイドラインの定義
実際の使用に関する情報を収集する方法の実装
TASの使用、利点、およびコストの監視
特定のTASのテストチームと開発チームにサポートを提供する
すべてのチームから学んだ教訓の収集
改善の特定と実装

　技術的な問題は、製品またはプロジェクトのリスクにつながる可能性がある。

抽象化が多すぎると、実際に何が起こっているかを理解するのが難しくなる
データ駆動型：データテーブルが大きくなりすぎ、複雑になり、扱いにくくなる
SUTのすべてのターゲット環境で利用できない可能性がある

　テストする新しいタイプのシステムに適応させたり、新しいソフトウェア環境
のサポートに対応したり、新しい法律や規制に準拠したりすることでTASを維持
することで、TASの信頼性と安全性を確保できる。

5. テスト自動化レポートとメトリクス

　TASメトリクスは、外部と内部の2つのグループに分類できる。

　外部メトリクス ：TASが他のアクティビティ（特にテストアクティビティ）に与える影響を測定するために使用されるもの。
　内部メトリクス ：TASの目的を達成する上での有効性と効率を測定するために使用される指標。
　測定されたTASメトリクスには通常、次のものが含まれる。

外部TASメトリクス

自動化のメリット
自動テストを構築するための努力
SUTの障害を分析する取り組み
- SUTおよびTASの利用可能なログは、障害の分析において重要な役割を果たす。
  →ログは、この分析を効率的に実行するのに十分な情報を提供する
自動テストを維持するための努力
欠陥に対する故障の比率
- テストの目的はソフトウェアの欠陥を強調することであるが、複数のテストで同じ欠陥を強調することは無駄である
自動テストを実行する時間
- 自動テストケースの数が増えるにつれて、このメトリクスは非常に重要になる
自動テストケースの数
合否結果の数
偽陰性および偽陽性の結果の数
- 誤警報は、テストコードの欠陥が原因で発生する可能性があるが、予測できない方法（タイムアウトなど）で動作する不安定なSUTが原因で発生する場合もある。テストフックは、干渉レベルが原因で、誤警報を引き起こす可能性もありる。
コードカバレッジ
- コードカバレッジが低下した場合、おそらく機能がSUTに追加されているが対応するテストケースが自動テストスイートに追加されていないことを意味する。

内部TASメトリクス

ツールスクリプティンングメトリクス
自動化コードの欠陥密度
TASコンポーネントの速度と効率
- TASは、SUTのパフォーマンスを妨げないように十分に機能している必要がある。パフォーマンスがSUTの重要な要件である場合、TASはこれを考慮した方法で設計する。

測定とレポート生成をサポートする自動化の機能

　テストの自動化には、テストの実行とテストの検証の両方の自動化が必要である。テストの検証は、テスト結果の特定の要素を事前に定義された期待される結果と比較することによって実現される。この比較は、テストツールで行うのが最適である。比較結果を考慮し、テストのステータスを正しく判断することが重要である。また、ステータスが失敗の場合は、失敗の原因に関する詳細情報が必要（スクリーンショットなど）となる。テスト結果はグラフで表示できるようにする必要がある。

6. 自動環境への手動テストの移行

自動化の基準

　自動テスト環境への移行を決定するときは、手動テストの現在の状態を評価し、これらのテスト資産を自動化するための最も効果的なアプローチを決定する。
　既存の手動テストの関連コンポーネント（入力値、期待される結果、ナビゲーションパスなど）を既存の手動テストから抽出し、自動化に再利用することもできる。
　以下の2点を考慮して移行する.

既存の手動テストの自動化への最初の変換
その後の新しい手動テストの自動化への移行

　特定の種類のテストは、信頼性テスト、ストレステスト、パフォーマンステストなど、自動化された方法でのみ（効果的に）実行できる。

　テストの自動化により、ユーザーインターフェイスなしでアプリケーションとシステムをテストできる。

　自動テストを開始する前に、自動テストと手動テストの作成の適用性と実行可能性を検討する。

自動化の複雑さ
ツールサポートの互換性
テストプロセスの成熟度
ソフトウェア製品のライフサイクルのステージに対する自動化の適合性
自動化環境の持続可能性
SUTの制御性

7. TASの確認

自動テスト環境コンポーネントの確認

　テスト自動化チームは、自動テスト環境が期待どおりに機能していることを確認する必要がある。

既知の合格テストケースが失敗した場合：何かが根本的に間違っていることは明らかなので、できるだけ早く修正する。
失敗したはずのテストケースに合格した場合：正しく機能しなかったコンポーネントを特定する必要がある。

自動テストスイートの確認

　自動テストスイートは、完全性、一貫性、正しい動作についてテストする。様々な種類の検証を適用して、自動テストスイートがいつでも稼働していることを確認したり、使用に適しているかを判断したりできる。検証内容には次のものがある。

既知の成功と失敗を含むテストスクリプトの実行
テストスイートの確認
フレームワークの新機能に焦点を当てた新しいテストの検証
テストの再現性を検討する
自動テストスイートに十分な検証ポイントがあることを確認

8. 継続的改善

テスト自動化を改善するためのオプション

　TASの改善は、効率の向上（手動による介入のさらなる削減）、使いやすさの向上、追加機能、テスト活動のサポートの向上など、様々な利点を実現するために行われる場合がある。どのように改善するかに関する決定は、プロジェクトに最大の付加価値をもたらす利点による影響をうける。

　改善が検討される可能性のあるTASの特定の領域には、次のものが含まれる。

スクリプト
テスト実行
検証
アーキテクチャ
前処理と後処理
ドキュメント
TASの機能
TASのアップデートとアップグレード