はじめに
テスト自動化エンジニアのシラバスを再度読み直し、各章をDailyで読めるようにしてみた
5 Implementation and Deployment Strategies for Test Automation を今回は翻訳・解説する
テスト自動化のパイプライン統合
パイプラインとは、ソフトウェア開発における一連の自動化されたプロセスを視覚的に表現したものです。
各プロセスは、前のプロセスから受け取った成果物を基に次のプロセスを実行し、最終的に製品を完成させる。
テスト自動化のパイプラインでは、コードの変更からデプロイまでの一連の工程を自動化し、テストを組み込むことで、ソフトウェアの品質を継続的に向上することができます。
テストレベルごとのパイプライン統合のポイント
-
TAF、TASの構成テスト
テストスクリプトで使用されるファイルのパスが正しく設定されているか、ファイルが存在するかを確認するためのテストです。 -
コンポーネントテスト
コードが小さな単位(ライブラリクラス、Webコンポーネントなど) でテストされるため、バグを早期に発見できます。
パイプラインの初期段階で品質を確保し、後工程への影響を最小限に抑えます。 -
コンポーネント統合テスト
複数のコンポーネントが連携して動作することを確認します。
コンポーネント間のインタフェースが正しく機能することを検証します。 -
システムテスト
システム全体の機能が要件を満たしていることを確認します。
パフォーマンス、セキュリティなど、非機能要件を検証します。 -
システム統合テスト
複数のシステムが連携して動作することを確認します。
システム間のデータ連携が正しく行われることを検証します。
継続的デリバリーパイプラインにおけるテストの統合
継続的インテグレーションシステムでは、継続的デリバリーパイプラインのビルドフェーズとデプロイフェーズが区別される。
-
ビルドフェーズ
コンポーネントテストとコンポーネント統合テストが実行されます。このフェーズが成功すると、コンポーネントやSUTがデプロイされます。 -
デプロイフェーズ
システムテストや受け入れテストが実行されます。テスト結果に基づいて、デプロイの成功または失敗が決定されます。
その他のテスト自動化のパイプライン活用
パイプラインは、以下のようなテスト自動化の目的にも利用できます。
- 定期的な回帰テスト
長時間のテストスイートを夜間実行し、翌朝にシステムの品質を確認します。 - 非機能テスト
パフォーマンステストやセキュリティテストなど、定期的に実行する必要がある非機能テストを自動化します。
テストウェアの構成管理
テストウェアとは、テストを行うために必要なすべての要素の総称です。
テストスクリプト、テストデータ、テスト環境設定などが含まれます。
構成管理は、これらの要素を効率的に管理し、一貫性を保つためのツールです。
構成管理の対象となるものとして、次のようなものがあります
テスト環境の構成
さまざまなURLや認証情報など、開発パイプラインで使用される各テスト環境の構成を管理します。
テスト環境の構成は通常、テストウェアと一緒に保存されます。
複数のプロジェクトや同じプロジェクトの複数のTAFで使用される場合は、共通のコアライブラリや共有リポジトリに保存できます。
テストデータ
テストデータは、テスト環境やSUTのリリース・機能セットに固有のものがあります。
テストデータは、通常、小さなTAFと一緒に保存されますが、テストデータ管理システムも使用できます。
テストスイート/テストケース
テストケースは、目的別に異なるテストスイートにグループ化されます（例えば、スモークテストや回帰テスト）。
異なるテストレベルで実行されるため、さまざまなパイプラインとテスト環境を活用します。
各SUTのリリースには、そのリリースの品質を評価するテストケースとテストスイートが含まれます。
機能トグルを使用して、リリースやテスト環境ごとに機能を有効化/無効化し、実行するテストスイートを制御できます。
SUTのバージョンとテストウェアのバージョンを一致させることで、テストの信頼性を確保できます。
テストウェアの構成管理のベストプラクティス
以下のことを考慮すると、テストウェアの構成管理がうまくいきます。
- バージョン管理
テストウェアをバージョン管理システム（Gitなど）で管理し、変更履歴を追跡します。 - モジュール化
テストコードをモジュール化し、再利用性を高めます。 - テストデータ管理
テストデータを適切に管理し、再利用できるようにします。 - 環境変数
テスト環境やデータの差異を環境変数で管理します。 - CI/CDパイプライン
テスト自動化をCI/CDパイプラインに組み込み、自動化されたテスト実行を実現します。
APIインフラのテスト自動化依存
APIのテスト自動化を行う際には、適切な戦略を構築するために、以下の依存関係に関する情報を理解することが重要です。
- API 接続
自動テスト対象となるビジネスロジックとAPI間の関係を理解します。 - APIドキュメンテーション
パラメータ、ヘッダー、リクエスト・レスポンスのオブジェクトの種類など、関連するすべての情報を含むAPIドキュメンテーションを参照します。
APIの自動化テストは、開発者またはテストエンジニア（TAE）によって実行できます。しかし、シフトレフトの原則に基づいて、異なるレベルでのテストをサポートし、分担することが推奨されます。
ISTQB CTFLシラバスでは、コンポーネント統合テストとシステム統合テストが挙げられていますが、それに加えて、次に説明する、契約テスト(Contract testing) というベストプラクティスを導入することができます。
契約テストは、サービス間の通信が正しく行われ、共有されるデータが特定のルールに準拠していることを検証する統合テストの一種です。
契約テストを使用すると、2つの異なるシステム（例えば、2つのマイクロサービス）が互いに通信するための互換性を確保できます。
スキーマの検証を超えて、両者が時間をかけて合意した一連のインタラクションを遵守することを要求します。
各サービス間で交換されるインタラクションをキャプチャし、契約として保存することで、両者が契約を遵守していることを検証できます。
契約テストの主な利点の一つは、基礎となるサービスの欠陥をSDLCの早期段階で発見し、その欠陥の原因をより容易に特定できることです。
コントラクトテストの消費者駆動アプローチでは、消費者（API呼び出し側）がその期待を設定し、提供者がこの消費者からの要求に応答する方法を決定します。
コントラクトテストのプロバイダー駆動アプローチでは、プロバイダー（API側）が契約を作成し、そのサービスの動作を示します。