はじめに
テスト自動化戦略のシラバスが今年2024年に公開された。
このシラバスを読みまして、各章をDailyで読めるようにしてみた
4 Organizational Deployment and Release Strategies for
Test Automation を今回は翻訳・解説する
テスト自動化による市場投入時間の短縮
テストサイクル時間の短縮
テスト自動化は、テストサイクル時間を短縮することで、ソフトウェアの市場投入を加速させます。
ソフトウェアリリース前のテストには、検証と妥当性確認が必要です。
特にリグレッションテストでは、テストの再利用を促進し、コストを削減し、テスト実行間の整合性を確保するため、重要です。
手動テストの削減と早期フィードバック
テスト自動化は、手動テストの労力を削減し、同じテスト範囲をカバーしながら開発者に迅速なフィードバックを提供できる。
また、コンポーネントテストやコンポーネント統合テストを自動化することで、ソフトウェア開発ライフサイクルの早期の段階でテストが可能になります。
一般的に、手動では実行しない
品質ゲートの活用
品質ゲートは、ソフトウェアが次のフェーズに進む前に満たす必要がある、プロセスに組み込まれた強制的な措置です。
テスト自動化を用い、品質ゲートを設定することで、プレプロダクション環境や本番環境への迅速なデプロイプロセスが可能になる。
これらの品質ゲートを活用することで、欠陥を早期に発見でき、市場投入時間を短縮できます。
並行テスト実行とShift Leftアプローチ
並行テスト実行とShift Leftアプローチにより、テスト実行時間を短縮できます。
Shift Leftアプローチは、品質意識の文化を促進し、ソフトウェア開発ライフサイクルの早期の段階でのテストを奨励している。
複数の独立したテストケースやクロスブラウザテストが含まれることもあります。
テスト自動化による不具合検証の効率化
不具合修正の検証
確認テストは、コード修正後不具合が修正されたかを確認するため実施される。
通常、テスターは不具合を再現するために必要なテスト手順に従い、不具合が解消されていることを検証します。
不具合は、後続のリリースで再発する可能性があります（例えば、構成管理やコードリポジトリ管理の問題が原因の場合）。
そのため、確認テストはテスト自動化の適任であり、既存の回帰テストスイートに追加することができます。
自動化による効率化
自動化された確認テストは、通常、機能範囲が狭く、不具合が報告され、それを再現するために必要なテスト手順が理解された時点で実装できます。
自動化された確認テストを追跡することで、不具合の解決に費やされた時間とテストサイクルの数を報告できます。
テスト自動化により、複数のプラットフォーム、デバイス、ブラウザ、OSバージョンにわたって修正を検証することで、テストに費やす時間を大幅に削減することができる。
運用のためのシナリオ開発のテスト自動化アプローチ
運用受け入れテストは、ソフトウェアが本番システムに適していることを保証するためのテストであり、リリース直前に実施されます。
この取り組みは、SUTのシステム、コンポーネント、その他のインフラストラクチャの最終的な検証と、本番環境への準備状況のテストを目的としている。
SUTがテスト環境外および本番環境で同じように動作するという保証がないため、必要となるテストである。
優れた運用テスト計画には、信頼性、フォールトトレランス、整合性、保守性のテストが含まれます。次にテスト自動化アプローチをあげる
- 静的コード分析
セキュリティや脆弱性をコード分析する自動化ツール。テスト結果は時間をかけてトレンド分析のために保存されます。 - エンドツーエンド(E2E)テスト
エンドツーエンドのユーザーシナリオを実行し、テスト環境のあらゆる側面を検証して欠陥を発見する自動化テストスクリプト。 - フェイルオーバーテスト
アプリケーションのハードウェアがオフラインになったときに何が起こるかを具体的にテストする自動化テストスクリプト。物理サーバーなどが誤動作時にアプリケーションがどのように回復するかなど。テストスクリプトは、SUTの自動回復能力の成功または失敗を測定するように設計されており、特にカオスエンジニアリングを実装している組織にとって重要です。 - バックアップと復元テスト
現在のバージョンのバックアップを作成し、以前のポイント（古いバージョンのソフトウェア）にロールバックする成功をテストする自動化テストスクリプト。 - パフォーマンス効率テスト（負荷テストなど）
多くのユーザーが同時にSUTを利用する状況をシミュレートするために使用できる自動化テストスクリプト。テスト結果は比較のために保存され、時間をかけてトレンド分析されます。 - 運用ドキュメントレビュー
自動化テストスクリプトを使用して、SUTのドキュメントのバージョンを比較し、特定のリリースに追加された新機能に基づいて更新が必要かどうかを開発チームに通知できます。 - セキュリティテスト
静的および動的な方法でSUTを評価するために、セキュリティテストツールと組み合わせて自動化テストスクリプトを作成できます。テスト結果は時間をかけて比較およびトレンド分析のために保存されます。 - 組織のサービスレベル契約に基づく監視
SDLC中に使用される自動化テストスクリプトを再利用して、本番運用の監視を行い、自動テストが失敗した場合にアラートを送信。実際のユーザーが経験する前に本番障害をキャッチするためのプロアクティブな方法。
運用ソフトウェアの検証におけるテスト自動化は、特に複数の環境で繰り返し実行できる場合に大きなメリットである。
専用の自動テストスイートを作成し、テスト結果を以前の実行と比較することで、新しいバージョンのSUTがリリースされる際の一貫性を確保できる。
信頼性の高い自動テストスイートは、長期的にコスト削減につながる。
テスト自動化の展開戦略
テスト自動化の展開戦略は、テスト環境、ツール、SUTへのアクセス、スクリプトの管理、データプロビジョニングなど、多岐にわたる要素を考慮する必要がある
テスト環境
複数のテスト環境で同じテストスクリプトが実行できるように、URLや認証情報などの設定をパラメータ化し、環境ごとに変更可能な仕組みを構築する。
環境固有の設定値を環境変数に格納することで、スクリプトの変更を最小限に抑え、異なる環境への適応性を高める
ツール
商用ツールの場合は、ライセンスサーバーへのアクセス権限やライセンス数の管理を徹底する
テスト対象システムやチームのスキルレベルに合ったツールを選択し、導入コストや学習コストを考慮する
SUTへのアクセス
複数のユーザーアカウントや異なる認証方式に対応できるように、認証情報を外部ファイルや設定ファイルで管理する。
SUTにアクセスする際は、可能な限りAPIを利用することで、安定性と効率性を向上させる。
テストスクリプトの管理
ソースコード管理ツールを活用し、テストスクリプトのバージョン管理を徹底する。
構成管理でテスト環境やツールに関する設定情報を、テストスクリプトと一元管理することで、環境間の差異を最小化します。
テストスクリプト、テストデータ、設定ファイルなどを全てリポジトリに格納し、チームで共有できるようにする
データプロビジョニング
静的なテストデータではなく、動的にテストデータを作成する仕組みを導入することで、テストの多様性を高める
テストデータのバージョン管理や共有を行い、テスト結果の再現性を確保する
テスト自動化の展開におけるリスクの特定
一般的な技術的問題
- キーワード駆動アプローチなど、過剰な抽象化により、テスト自動化コードの実際の動作が理解しにくくなる
- テストデータテーブルが複雑になると、他のテスト環境への移行が困難になり、結果としてステータスの不一致が生じる可能性がある
- TAS が特定の OS ライブラリや他のコンポーネントに依存している場合、それらがすべての SUT テスト環境で利用できない可能性があります。
この他にも、過剰な抽象化による複雑さ、テストデータ管理の課題、特定のコンポーネントへの依存などが含まれる
一般的な展開プロジェクトリスク
- テスト自動化を維持する適切な人材の確保が困難
- SUT の更新によりTAS修正が発生し、計画外のメンテナンスが必要になる
- テスト自動化の導入の遅れ
- SUT の変更に基づく TAS の更新の遅れ
- TAS が非標準の UI オブジェクトをキャプチャできない
- 古いテストケースをテストスイートに残したままにし、テスト実行時間を無駄にする
この他にも、、人員の確保の難しさ、システム更新によるメンテナンスの問題、展開の遅れ、古いテストケースの存在なども考慮する必要があります。
TAS プロジェクトの潜在的な失敗ポイント
- 異なるテスト環境への移行
- 本番環境への展開
- 自動化もソフトウェアであり、テストされるべきであることを忘れる
さらに、異なる環境への移行や自動化ソフトウェア自体のテストの必要性を無視するなどの潜在的な失敗ポイントに対しても、適切な計画を立てて対処する必要があります。
これら３つのポイントは、テスト自動化プロジェクトの成功を危うくする可能性があることに注意してください。
全体として、監視と積極的な対策により、テスト自動化プロジェクトの成功を確保することができます。
展開リスクを軽減するためのアプローチの定義
TAS は独自の SDLCがあり、構成管理下にあり、その機能が文書化されている必要がある。
さもないと、そのさまざまな部分を展開して連携させたり、特定のテスト環境で動作させたりすることが非常に困難になる。
また、文書化され、明確で、かつ従いやすい展開手順が必要です。この手順はバージョンに依存するため、構成管理下にも含める必要があります。
TAS の展開には、次の 2 つの異なるケースがあります。
- 初回展開
- メンテナンス展開 - TAS が既に存在し、更新を展開する必要がある場合
初回展開に関連するリスク
テストスイートの総実行時間がテストサイクルの計画のテスト時間より長くなる可能性があり、十分な時間を計画することが重要です。
テスト環境にインストールおよび構成の問題が存在する（データベースのセットアップと初期ロード、サービスの起動/停止など）。
TAS には、テストケースがテスト環境内で実行するために必要な前提条件を作成するためのテストフィクスチャ（事前に定義されたデータセット）が必要です。
メンテナンス展開の考慮事項
TAS 自体が進化する必要があり、その更新を本番環境に展開する必要がある。
更新されたバージョンの TAS を本番環境に展開する前にテストが必要がです。
そのため、新しい機能をチェックし、テストスイートを更新された TAS で実行できること、テストレポートを送信できること、パフォーマンスの欠陥やその他の品質の問題がないことを確認する必要がある。
場合によっては、テストスイート全体を最新バージョンの TAS に適合させる必要がある時もある
テスト環境におけるテスト自動化コンポーネントの定義
-
SUT
これはテスト環境の明白な部分です。SUT は全体としてテストすることも、サブコンポーネント（API、Web ベースのインターフェイス、データベースなど）に分割してテストすることもできる -
プラットフォーム
プラットフォームは、テスト自動化コンポーネントがホストされる場所を記述します。これには、クラウドインフラストラクチャ、ネットワーク、仮想マシン、およびコンテナが含まれ、これらはテスト自動化を効率的で移植可能にするために使用できます。 -
テストケースとテストスイート
これは、自動化されたアクションと手動のアクションの両方を指示するテストステップで構成される個々のテストケースを記述します。テストスイートは、テストケースの論理的なグループ化を記述し、効率的に一緒に実行できるようにします。 -
ツール
さまざまなテスト自動化ツールがさまざまな理由で使用されます。ツールのコレクションには、UI テスト自動化、API エンドポイントのテスト、データ生成、監視、要件管理、欠陥管理、ログおよびレポートツール、およびメトリックに基づいてトレンドを生成するためのツールが含まれます。 -
TAF
これには、TAF 設計を構成するすべてのアイテムが含まれる。TAF には、ドライバースクリプト、共通ライブラリ、自動化テストケースのテンプレート、データのロード/プロビジョニングスクリプト、TAF コンポーネントの使用方法に関するドキュメント、TAE が TAF を利用するのに役立つチュートリアルが含まれます。
テストコンポーネントのメンテナンスは重要な考慮事項です。
テスト環境を過度に複雑にすると、TAF の欠陥を修正するのに不要な時間を費やすことになり、ソリューションのメリットが得られなくなる。
コンポーネントを可能な限り再利用できるように、適切なツール、構成、およびプラットフォームの移植性のバランスを見つけることが重要。
インフラストラクチャコンポーネントとテスト自動化の依存関係を特定
テスト自動化を組み立てる際には、多くのインフラストラクチャコンポーネントと依存関係に注意する必要がある
これらは総称して、TAS を実行するために必要なすべての前提条件をカバーします。
主なコンポーネントと依存関係には以下が含まれます。
-
ホストマシン
仮想マシン、物理サーバー、ラップトップ、デバイス（タブレット、モバイルなど）など。これらにはテスト自動化ソフトウェアがインストールされており、テストスクリプトの作成と実行が行われます。 -
ネットワーク
これは、TAS が SUT にアクセスするためのもの。複数のホストマシンをネットワークで接続して、自動テストを並行して実行することもできる。通常、ホストマシンは同じネットワーク上にあり、互いに通信できるように適切に構成されている必要があります。 -
プラットフォーム
テスト自動化は他のソフトウェアと同様に、クラウドプラットフォーム上で実行することも、コンテナ内で実行するように設計することもできる。プラットフォームが基盤となる OS への権限とアクセスを提供する限り、必要なすべてのツールと依存関係をインストールできる。 -
ソフトウェア依存関係
テスト自動化ツールを正しく動作させるためには、テスト自動化が持つ他のすべての依存関係を理解する必要がある。たとえば、特定のテスト自動化ツールは、まずホストマシンに最新バージョンのプログラミング言語をインストールする必要があるかもしれません。TAE は、ツールを選択する前後にこれらの依存関係を考慮する必要がある。 -
SUT
コンポーネント、依存関係、および全体的なインフラストラクチャを考慮して適切に構成したら、最後のステップは SUT へのアクセスを確保することです。ネットワークに加えて、SUT とどのようにインターフェースするかを考慮する必要もあります。たとえば、Webアプリケーションでは、ホストマシンにブラウザをインストールする必要があります。ブラウザの種類とバージョンを考慮する必要があります。
テスト自動化データとインターフェース要件を定義
テスト自動化スクリプトを開発する前に、SUTとどのようにインターフェースするか、およびテストケースのデータ依存関係は何であるを考慮する
-
API
SUT が API を利用している場合、アプリケーションレベルで UI を必要とせずに、エンドポイントレベルでテストできます。これには、UI によって隠されているエンドポイントとデータ通信のより深い理解が必要になる場合があります。ビジネスプロセスを作成するために APIを呼び出す順番、テストケースを維持するためにデータをどのように関連付けるかを理解する必要がある。 -
データベースインターフェース
一部のテスト自動化ツールは、SUT の基盤となるデータベースと直接インターフェースする機能を持つ。テストスクリプトは、ストアドプロシージャやその他のデータベースルールが正しく構成されていることを確認するために記述できる。これには、信頼性テストのためにデータベースに特定のデータ値が既に存在している必要がある場合があります。 -
インターフェース互換性
契約テストを使用すると、2 つの別個のシステムが互換性があり、互いに通信できるようになります。契約テストは、消費者主導、生産者主導、および双方向のいずれかになります。
さらに、TAE は、SUT とどのようにインターフェースするかを慎重に検討し、テストケース内のデータ依存関係を理解する必要がある。
API、データベースインターフェース、またはシステム間のインターフェース互換性の確保のいずれの場合でも、これらの考慮事項に注意を払うことは、堅牢で効果的なテスト自動化にとって不可欠です。
これらの要因を慎重に検討することで、TAE は自動化の信頼性と効率を高め、最終的に SUT の品質と成功に貢献できます。