Outline
ISQTBのテスト自動化のシラバス「Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) 」が 2024年5月に v2.0 にバージョンアップしました。
英語翻訳、自己解釈したものをつらつらと記載しました No.2
長いので、分割して記事にした。
なお、本記事に使用した図はISTQBシラバスのものである。
関連記事
7 テスト自動化ソリューション(TAS)の検証
7.1 テスト自動化インフラの検証
7.1.1 テストツールセットアップを含めた環境の検証プラン
テスト自動化環境およびTASの他のすべてのコンポーネントが期待通りに動作するかどうかを確認する必要があります。
この検証は、例えば、テスト自動化を開始する前に行われます。
テスト自動化環境のコンポーネントを検証するための手順が取られます。
各手順については以下で詳しく説明します。
テストツールのインストール、セットアップ、カスタマイズ
TASは多くのコンポーネントで構成されています。
それぞれのコンポーネントが信頼性と再現性のあるパフォーマンスを確保することが期待されている。
TASのコアは、実行可能なコンポーネント、関連関数ライブラリ、サポートデータおよび設定ファイルである。
TASの設定プロセスは、自動インストールスクリプトから、対応するフォルダに手動でファイルを配置するなどいろいろある。
テストツールは、OSや他のソフトウェアと同様に、定期的にサービスパックが提供されたり、特定のSUT環境との互換性を確保するためにオプションまたは必須のアドインが必要となることがある。
自動インストールやリポジトリからのコピーにはメリットがある。
これにより、異なるSUTで同じバージョンのTASおよび同じ設定のTASが使用できることが保証される。
TASのアップグレードはリポジトリを通じて行うことができ、リポジトリの使用および新しいバージョンのTASへのアップグレードプロセスは、一般的な開発ツールと同じである。
テスト環境のセットアップ・ティアダウンの再現性
TASは、さまざまなシステム、サーバー、そしてCI/CDパイプラインをサポートするように実装されている。
TASが各テスト環境で適切に確実に動くように、任意のテスト環境からTASをロードおよびアンロードするシステマティックアプローチが必要です。
これを達成する条件は、TASのビルドおよびリビルドが、複数のテスト環境内および環境間での動作において差異なく提供する時である。要するに環境依存しないこと。
TASコンポーネントの構成管理により、特定の構成が確実に作成できるようになる。
これが達成されると、TASを構成するさまざまなコンポーネントを文書化することで、SUT環境が変更された場合にTASのどの側面が影響を受けるか、または変更が必要かについての必要な知識が提供できる
システム、インターフェースの内外の接続性
TASがSUT環境にインストールされた後、SUTを使用する前に幾つかの確認や前提条件を満たすことで、内部システム、外部システム、およびインターフェースへの接続が利用可能であることを確認できる。
例えば、以下のような手順が良い実践例です
- サーバーへのログイン
- テスト自動化ツールの起動
- テスト自動化ツールがSUTにアクセスできることの確認
- 手動で設定確認
- システム間のテストログ、レポートが正しく行われるかの権限設定の確認
テスト自動化の前提条件を構築することはTASが正しくインストール、設定されていることを確認するに必須である。
TAFコンポーネントテスト
7.1.2 テスト自動化スクリプト、スイートの期待通りの動作
自動テストスイートは、完全性、一貫性、および正しい動作についてテストする必要がある。
さまざまな種類の検証チェックを使って、自動テストスイートがいつでも使用可能であるか、使用に適しているかを確認する。
テスト自動化スイートの検証ステップ：
- テストスイートの構成確認
- TAFの新機能の新しいテストの検証
- テストの再実行性の考慮
- テスト自動化の悪影響の考慮
テストスイートの構成確認
テストの完全性（たとえば、すべてのテストケースに期待値があり、テストデータが存在する）の検証、TAFとSUTの正しいバージョンの確認。
TAFの新機能の新しいテストの検証
TAFの新機能が初めてテストケースで使用される時、機能が正しく動作していることを確認するために、綿密に検証および監視する必要がある。
テストの再実行性の考慮
テストを繰り返す場合、テスト結果は常に同じである。
信頼性の低いテスト結果（例えば、競合状態による）のテストケースがテストスイートにある場合、自動テストスイートから移動してディアクティベイトし、根本原因を特定するために別途分析する必要がある。
さもないと、これらのテスト実行が常にエラーを引き起こし、繰り返し分析するために時間が費やされる。
テスト自動化の悪影響の考慮
TASは、SUTと密接に結びつきやすい。
これは、相互作用のレベルに関してより良い互換性を持たせるための設計です。
しかし、この密結合は、逆効果を招くこともあります。
例えば、TASがSUT環境内にある場合、手動でテストを行うときとは異なる機能動作を示すことがあり、パフォーマンスにも影響を与える可能性があります。
高いレベルの干渉は、テスト中に本番環境では明らかにならない失敗を示すことがある。
これが自動化テストの失敗を引き起こすと、TASへの信頼が大幅に低下する可能性があります。
開発者は、容易に分析したいために、自動化テストで特定された失敗を手動で再現することを求める場合がある、
7.1.3 テスト自動化で期待外になる場所を特定する
テストスクリプトが予期せず失敗または成功した場合、根本原因分析を実行する必要がある。
検証する対象は以下のものがある
- テストログ
- パフォーマンスデータ
- テストスクリプトのセットアップとティアダウン
いくつかの単独のテストを実行することも役立つ。
間欠的な障害は分析が困難。
欠陥は、テストケース、SUT、TAF、ハードウェア、またはネットワークにある可能性がある。
システムリソースの監視は、根本原因のヒントを得るのに役立つ可能性があります。
テストケース、SUT、およびTAFのテストログファイルの分析は、欠陥の根本原因を特定するのに役立つ場合があります。
デバッグも必要です。
根本原因を特定するために、テストアナリスト、ビジネスアナリスト、開発者、またはシステムエンジニアのサポートが必要になる場合があります。
アサーションがすべて配置されていることを確認する。
もし、アサーションが欠けていると、テスト結果が不確実になる可能性があります。
7.1.4 静的解析がテスト自動化コード品質にどのように役立つか？
コードの静的解析は、プログラムコードの脆弱性や欠陥を発見するのに役立ちます。これには、SUTまたはTAFが含まれる。
自動スキャンは、コードを検査してリスク軽減することができる。
これは、欠陥についてSUTのレビューを提供し、コード品質基準が満たされ適用されていることを保証する。
これはまた、プロアクティブな欠陥検出技術と見なすことができ、DevSecOps実装（セキュリティを重視したDevOps）において重要な役割を果たす。
開発チームに即時のフィードバックを提供するために、これらのスキャンはSDLCの初期段階で行う。
欠陥に関する出力は通常、重大、高、中、低の深刻度に分類され、開発チームが修正する欠陥の優先順位を決定しやすくする。
特定の静的解析ツールは、発見した欠陥に対するコード修正の提案も提供する。
これにより、問題のあるコード行のコピーと、開発者が実装できる可能な修正案が出てくる。
さらに、これらのツールは、品質を測定し、コメントを追加すべき箇所を提案し、リソース処理の最適化（例：try/catchブロックの利用やより良いループ構造）や不適切なライブラリ呼び出しの削除を通じて、コード設計の改善をサポートする。
テスト自動化ツールがプログラミング言語を使用するため、不適切なテスト自動化コードがソフトウェア開発ライフサイクル（SDLC）に導入されるリスクがある。
簡単な例として、テストを自動化する際にユーザー名とパスワードを使用するのが一般的ですが、TAEがパスワードをプレーンテキストで1つまたは複数のテストスクリプトに誤って含めてしまうことが考えられる。
静的解析ツールは、テスト自動化コードのセキュリティ違反（コード内のプレーンテキストパスワードなど）を発見することもできる。
静的解析ツールは、テスト自動化ソフトウェアで使用される多くのプログラミング言語をサポートしています。
したがって、TAEは、コードのスキャンに関するベストプラクティスを拡張して、テスト自動化コードも含めることが重要。
テスト自動化コードは必ずしも全体的なソフトウェアと一緒に展開されるわけではありませんが、パスワードが添付の自動化テストスクリプトで見つかった場合、明らかに潜在的な脆弱性がある（参考 ISTQB CT-SECシラバス）。
8 継続的な改善 CI
8.1 テスト自動化のCIの機会
8.1.1 データ収集と分析によるテストケース改善の機会発見
データ収集と分析は、以下の手法でさまざまな種類のデータを考慮すると改善できます。
テストヒストグラム
テストデータをテストヒストグラムとして視覚的に表現したレポートは、テストケースデータのトレンドに関する潜在的な改善点を示す。
多くのCI/CDおよびテストレポートツールが異なるテスト結果とそのそれぞれのテストデータ（例：例外ログ、エラーメッセージ、スクリーンショット）を表示できるため、TAEは可能な改善領域を決定できる。
TAEはテストヒストグラムを使って、脆弱なテストケースを特定して選択し、追加の改善または実際の実装の再考でリファクタリングできる。
人工知能 (AI)
AIをテストとテスト自動化のサポートに最近使用され出している。
たとえば、UIテストケースでは、データには入力として扱えるUIロケーター値も含まれます。
最近の最先端ツールは、特定のロケーターが使用されているものから変更されているかどうかを検出する機能がある。
機械学習(ML)と画像認識に基づいて、新しいセレクターを識別し、自己修復アルゴリズムを使用してテストケースを修正し、変更されたロケーターをテストレポートに含めることができる。
これにより、バージョン管理の変更やコードメンテナンスなどのフォローアップステップを迅速化できる。
スキーマバリデーション
スキーマバリデーションは、APIデータ分析（例：ターゲットエンドポイントから派生したプロパティ）やデータベース分析（例：許可されるデータ型や値の範囲などのソフトウェアフィールドのバリデーションルール）に適用される。
スキーマバリデーションを使用することで、TASはレスポンスが実際のビジネス仕様に一致しているかどうかを確認することができる。
このようなチェックは、サービスレスポンスに必須のレスポンス要素が存在し、そのオブジェクトタイプがスキーマで定義されたものと一致しているかどうかを判断するために使用される。
スキーマが壊れた場合、ソリューションは実際のバリデーションを返し、TAEが問題の根本原因を特定するのに役立ちます。
例：あるAPIには、レスポンス内で文字列でなければならない6つの必須レスポンス要素を持つ。
スキーマバリデーションツールを使用すると、これらのタイプが文字列であり、その値がnullでないことを確認するために個別のアサーションを書く必要がありません。
スキーマバリデーションがこれらのチェックを処理するため、実装されたテスト自動化コードが短くなり、バックエンドサービスの欠陥検出の効率が向上する。
8.1.2 テスト自動化ソリューションの技術的側面の分析、改善のための推奨事項を提供
TASをSUTと同期させるための継続的なメンテナンス作業に加えて、TASを改善するための多くの可能性がある。
これらの改善により、手動介入のさらなる削減などの効率向上、使いやすさの向上、追加機能の提供、テストサポートの強化など、さまざまなメリットになる。
TASの改善方法は、プロジェクトに最も価値をもたらす機能によって影響される。
以下は、改善が検討される具体的なTASの領域です：
スクリプティング
スクリプト技法は、線形スクリプトからデータ駆動型テストアプローチ、そしてより洗練されたキーワード駆動型テストアプローチまで、色々ある（3.1.4参考)。
すべての新しい自動化テストに対して現在のTASスクリプト技法をアップグレードすることが適切かもしれない。
すべての既存の自動化テスト、または少なくとも最も多くのメンテナンス作業を伴うものが、この技法により改良される。
テストスクリプトの実装に焦点を当てたTASの改善も重要です。以下はその具体例です：
テストスクリプト/テストケース/テストステップを評価し、自動テストの重複を統合：
類似したアクションシーケンスを含むテストケースは、これらのテストステップを複数回実装するべきではない。
これらのテストステップは、関数にしてライブラリする。
これにより、これらのライブラリ関数を異なるテストケースにて再利用でき、テストウェアの保守性が向上する。
テストステップが同一ではないが類似している場合、パラメータ化が必要になる場合があります。（これは、キーワード駆動型テストの典型的なアプローチ）
TASとSUTの障害回復プロセスの確立：
テストスイートの実行中に障害が発生した場合、TASは後続する可能なテストを継続させるため、この状態から回復できる必要がある。
SUTで障害が発生した場合、TASは可能な限り実行可能なSUT上で必要な回復アクションを実行する必要がある。
最適なタイプが使用されていることを確認するための、テストの待ちメカニズムを評価：
3つの一般的な待ちメカニズムがある。
ハードコードされた待機時間：
一定のミリ秒数を待機するハードコードされた待機時間は、ソフトウェアの応答時間が予測不可能なため、多くのテスト自動化の欠陥の原因となります。
動的待機（ポーリング）：
特定の状態変化やアクションが発生したかどうかをチェックして、変化するまでまつ。
必要な時間だけ待機し、テスト時間が無駄にならず、柔軟で効率的である。
プロセスが予想より長くかかる場合でも、条件が真になるまで待機します。
ただ、タイムアウトメカニズムを含めることが重要です。そうしないと、欠陥がある場合にテストが永遠に待機する可能性がある。
イベントサブスクリプション：
SUTのイベントメカニズムにサブスクライブする方法です。（イベントハンドラー）
他の2つのオプションよりも信頼性が高いです。
これを実現するには、テストスクリプト言語がイベントサブスクリプションをサポートし、SUTがこれらのイベントをTASに提供する必要がある。
タイムアウトメカニズムも必要です。欠陥がある場合にテストが永遠に待機するのを防ぐためです。
テスト実行
自動化されたリグレッションテストスイートの実行が長時間かかりすぎて完了しない場合、可能であれば異なるテスト環境で並行してテストを実行することが必要になるかもしれない。
高価なシステムを使用してテストを行う場合、すべてのテストを単一のターゲットシステムで実行しなければならないという制約になる。
このような場合の改善ポイント：
回帰テストスイートを複数の部分に分割し、それぞれを一定の期間内（例：一晩）に実行することが必要になるかもしれません。
テスト自動化カバレッジのさらなる分析により、重複が明らかになる可能性があります。
重複を削除すると、テスト実行時間を短縮し、さらなる効率化を実現できます。
CI/CDの場合、テスト実行時間を最適化するために、バッチジョブを並列実行することがベストプラクティスです。
また、自動化されたバッチジョブをスケジュールして、特定の時間に異なるパイプラインを実行することは、手動のやり取りを減らし、開発プロセスをスピードアップするための良いプラクティスです。
検証
テストケースを作成する前に、すべての自動化テストで使用するための標準検証方法のセットを採用するとよい。
これにより、複数のテストで検証アクションを再実装するのを避けることができます。
検証方法が同一ではないが類似している場合、パラメータ化を使用し、関数を複数のタイプのオブジェクトで使用できるようになる。
TAA（テストアーキテクチャアプローチ）
テストのテスト可能性を向上させるために、TAAを変更する必要がある場合がある。
これらの変更は、SUTのアーキテクチャまたはTASのTAAで行われる。
これによりテスト自動化を大幅に改善できますが、SUT/TASに大きな変更と投資が必要になる場合があります。
たとえば、SUTがテストのためにAPIを提供するように変更される場合、TASもそれに応じてリファクタリングする必要があります。
これらの種類の機能をSDLCの後期に追加することは非常に高価になる可能性があります。
テスト自動化開始時に、もしくは早い段階で考慮すべきである。
TAF（テストオートメーションフレームワーク）
多くの場合、TAFで使用されるコアライブラリの新バージョンがあります。
これらのバージョンはメジャーアップデートであり、最新バージョンは、TAFの依存関係リストで直ちに参照することはできません。なぜなら、チームが使っているテストが壊れる可能性があるからです。
そのため、まずパイロットとインパクト分析を実行する。
その後、採用計画を作成できます。
コアライブラリレイヤーのビルドファイルで依存関係を更新することで、すべてのチームが同時にコアライブラリの新バージョンを採用するか、各チームがビジネスロジックレイヤーでいつ更新するかを個別に決定します。
最終的に、すべてのチームがコアライブラリの新バージョンを受け入れる準備ができたら、コアライブラリレイヤーで依存関係を更新する（3.1.3参照）。
セットアップとティアダウン
繰り返し実行されるアクションや設定は、セットアップまたはティアダウンメソッドに移動することが推奨する。
セットアップ:
テストの前に実行される初期設定を行う。
例: データベース接続の確立、テストデータの準備、Webサービスの呼び出しなど。
ティアダウン:
テストの後に実行されるクリーンアップ作業を行う。
例: データベース接続の切断、テストデータの削除、Webサービスの呼び出しなど。
これにより、コードに影響を与える変更を一箇所で更新でき、メンテナンスの手間が減少します。
例えば、UIテストの前提条件や後処理を満たすために、Webサービスコールを使用することができます（例：ユーザー登録、ユーザーのクリーンアップ、プロファイル設定）。
ドキュメント
ドキュメントは、テスト自動化の成功に不可欠な要素です。
- テスト自動化ドキュメント
- TASのユーザードキュメント
- テストレポートとテストログ
TASの機能
新しい機能を追加する際には、実際に使用される機能のみを追加することが重要です。
未使用の機能を追加すると、システムの複雑さが増し、信頼性とメンテナンス性が低下する可能性があります。
TASのアップデートとアップグレード
新しいバージョンのTAFにアップデートまたはアップグレードすることで、新しい機能が利用可能になり、テストケースで使用できるようになったり、既存の問題が修正されたりすることがあります。
しかし、既存のテストツールをアップグレードしたり、新しいツールを導入したりすることで、既存のテストケースに悪影響を与えるリスクもあります。
テストツールの最新バージョンをロールアウトする前に、サンプルテストを実行してテストツールをテストする。
サンプルテストは、さまざまなSUT、テストタイプ、そして、適切な、さまざまなテスト環境の自動テストを代表するものでなければなりません。
8.1.3 自動テストウェアをSUTの変更に合わせて再構成
特定のSUTに対する一連の変更に従うと、TAFおよびコンポーネントライブラリを含むTASの更新が必要になる
どれだけささいな変更でも、TASの信頼性とパフォーマンスに広範囲にわたる悪影響を及ぼす可能性がある。
テスト環境コンポーネントの変更を特定
テスト環境のコンポーネントに対する変更や改善が必要かどうかを評価する。
これらの変更は、テストウェア、カスタマイズされた関数ライブラリ、またはオペレーティングシステムに対する変更を必要とされる可能性がある。
これらの変更は、TASのパフォーマンスにも影響を与える可能性がある。
全体的な目標は、自動化されたテストが効率的に実行され続けること。
最小限の実行可能な製品（MVP）のマインドセットで変更を段階的に行うべきです。
これにより、TASへの影響を限定的なテストスクリプトの実行を通じて測定できる。
副作用がないことが確認されたら、変更を完全に実施する。
変更が自動化テストスクリプトに悪影響を与えなかったことを確認するための最後のステップは、完全なリグレッションテストの実行です。
これらのリグレッションテストスクリプトの実行中に、失敗が発生することがあります。
この失敗の根本原因を特定すること（例：テストレポート、テストログ、テストデータの分析を用いる）は、テスト自動化の改善活動によるものではないことを確認する手段となる
コアのTAS関数ライブラリの効率性と有効性の向上
TASが成熟するにつれて、タスクをより効率的に実行する新しい方法が見つかる。
これらの新しい技術（例：関数内のコードの最適化や新しいOSライブラリの使用）は、現在のプロジェクトおよび将来のプロジェクトで使用されるコア機能ライブラリに組み込む必要があります。
同じコントロールタイプに対して動作する複数の関数を統合する
自動化テストの実行中に大部分を占めるのは、GUI内のコントロールの調査です。
この調査は、コントロールに関する情報（例：表示/非表示、有効/無効、サイズと寸法、データ）を提供するために行われる。
この情報を基に、自動化テストはドロップダウンリストから項目を選択したり、フィールドにデータを入力したり、フィールドから値を読み取ったりすることができる。
コントロールに対して情報を引き出すために動作する関数は複数ある。
いくつかの関数は非常に専門的である一方、他の関数はより一般的な性質を持っている。
例えば、ドロップダウンリストのみに対応する特定の関数がある。
あるいは、関数をパラメータとして指定することで、複数の機能に対応する関数もある。
したがって、TAEは少ない関数にまとめられた幾つかの機能を使っても同じ結果になり、メンテナンスを最小限に抑えることができる。
TAAのリファクタリングしてSUTの変更に対応する
TASのライフサイクルを通じて、SUTの変更に対応するために変更が必要となる。
SUTが進化し成熟するにつれて、基盤となるTAAも進化し、SUTをサポートする能力を確保する必要があります。
機能を拡張する際には、ボルトオン方式、つまり安易な拡張、で実装するのではなく、TAA内で分析し変更を加えるように注意する必要がある。
これにより、新しいSUT機能が追加のテストスクリプトを必要とする場合でも、これらの新しい自動化テストに対応できる互換性のあるコンポーネントが整備されることが保証される。
命名規則と標準化
変更が導入される際、新しいテスト自動化コードや関数ライブラリの命名規則は、以前に定義された標準（4.3.1を参照）と一貫している必要がある。
SUTの改訂や削除に伴う既存のテストスクリプトの評価
変更と改善のプロセスには、既存のテストスクリプトの評価、その使用状況、および継続的な価値の評価も含まれる。
例えば、特定のテストが複雑で実行に時間がかかる場合、それらを小さなテストに分解することで、より実行可能で効率的になる場合がある。
また、頻繁に実行されない、またはまったく実行されないテストを対象にして削除することで、TASの複雑さを削減し、維持すべき内容をより明確にすることができる
8.1.4 テスト自動化ツールの活用機会のまとめ
テスト自動化は、実際のテスト以外にも以下のような非特定のテスト活動に役立ちます：
環境構築と制御
特定のテストスクリプト（例：テストデータの作成）は、セットアップメソッドで活用して新しいテスト環境で異なるテストデータを作成することができる。
例えば、異なるデータ入力に基づいて複数のプロファイルを持つユーザーを作成する必要がある場合、チームは自動化されたテストスクリプトを使用して、これらのユーザーを登録するWebサービスのエンドポイントを呼び出すことができる。
テストスクリプトは、テストインフラのセットアップを制御し、プロセスの後にクリーンアップを行うためにも活用できる。
これにより、時間を節約し、各新しいテスト環境に適切なユーザーが存在することを確保できる。
例えば、異なるテストログやその他のテストウェアをテスト環境から自動的に削除することで、維持管理とテスト環境の利用効率を向上させることができる。
データエイジング
テスト環境のテストデータを操作するために、テスト自動化が使われる。
たとえば、データベースでは、日付フィールドをチェックして制御して、年単位で最新の状態に保つことができます。
スクリーンショットや動画生成
ほとんどの最新のUIテスト自動化ツールには、特定の条件でスクリーンショットやビデオを作成して保存する組み込み機能を持つ。
これらのテストツールを使用することで、実際の使用のスクリーンショットやビデオをソフトウェアリリースドキュメントやマーケティング目的で作成し、ビジネスをサポートできる。