2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

テスト自動化エンジニアシラバス:テスト自動化を実現するためのインフラ構成

Last updated at Posted at 2024-12-02

はじめに

テスト自動化エンジニアのシラバスを再度読み直し、各章をDailyで読めるようにしてみた

今回、2.1 Understand the Configuration of an Infrastructure to Enable Test Automation を翻訳・解説する。

テスト自動化の実装に必要なインフラ構成

テスト自動化の実装には、テスト対象システム(SUT)のテスト可能性(Testability)が重要です。
テスト可能性とは、システムの内部状態を観測し、制御するためのソフトウェアインターフェースが提供されているかどうかです。

ソフトウェアアーキテクトは、システムの非機能要件としてテスト可能性を考慮し、テスト自動化エンジニア(TAE)と協力して改善すべき点を特定する。

テスト可能性を高めるための手法

アクセシビリティ識別子

  • UI要素の特定
    ボタン、テキストボックスなど、UI要素をプログラムで一意に識別するためのIDや名前のようなもの。
  • 自動生成と手動設定
    開発フレームワークによっては自動生成されますが、より柔軟な制御が必要な場合は手動で設定することも可能。

例: SeleniumでWeb要素を特定する際のID属性、XPathなど

システム環境変数とデプロイメント変数

  • 設定の変更
    アプリケーションの動作を制御するパラメータを、環境変数やデプロイメント変数で設定することで、テスト環境に合わせて柔軟に設定変更できます。

例: テスト用データベースへの接続情報、ログ出力レベルなど

アーキテクチャの透明性

  • ドキュメントの重要性
    システムのアーキテクチャを明確に記述したドキュメントは、テストケースの作成やトラブルシューティングに役立つ。
  • 観測性と制御性の確保
    各コンポーネントの役割やインターフェースが明確に定義されていれば、テスト対象を特定しやすくなる。

テスト可能性のための設計要素

Observability (観測可能性)

SUTは、その内部状態を外部から観測するためのインターフェースを提供する必要があります。
テストケースはこれらのインターフェースを使用して、実際の結果と期待される結果を比較できます。

  • 内部状態の可視化
    システムの内部状態(変数の値、処理の経過など)を外部から確認できる必要があります。
  • ログの出力
    処理の経過やエラー情報をログに出力することで、問題発生時の原因究明を容易にします。
  • モニタリング
    システムの稼働状況をリアルタイムで監視し、異常を検出します。
  • デバッグ用インターフェース
    開発者がシステムの内部状態を直接確認するためのデバッグ用インターフェースを提供します。

Controllability (制御可能性)

SUTは、操作するためのインターフェースを提供する必要があります。
これには、UI要素、関数呼び出し、通信要素(TCP/IP、USB)、物理的または論理的なスイッチの電子信号などが含まれる。

  • 入力の制御
    システムに与える入力(データ、イベントなど)を自由に制御できる。
  • 状態の変更
    システムの状態を任意に設定できる。
  • 処理の切り替え
    特定の処理を実行したり、スキップしたりできる。

Architecture transparency (アーキテクチャの透明性)

アーキテクチャのドキュメントは、明確で理解しやすいコンポーネントとインターフェースを提供し、すべてのテストレベルでの観測可能性と制御可能性を確保し、品質を促進する必要があります。

テスト自動化と様々な環境での活用

異なる種類の自動化テストは、さまざまな環境で実行できます。
これらの環境はプロジェクトや手法によって異なる場合がありますが、ほとんどのプロジェクトでは、テストのために1つ以上の環境が利用されます。
技術的な観点から、これらの環境はコンテナ、仮想化ソフトウェア、その他の方法を使用して作成できます。

様々なテスト環境とその役割
テスト自動化では、以下のような様々な環境が活用されます。

ローカル開発環境

  • 開発者が自身のマシン上でコードを書き、小さな単位でテストを行う環境
  • コンポーネントテストや単体テストが中心
  • IDE(統合開発環境)を活用し、デバッグを行いながら開発を進めることができる

ビルド環境

  • コードをビルドし、基本的な動作確認を行う環境
  • CI/CDツールと連携し、自動でビルドとテストを実行
  • 静的解析やコンポーネント統合テストなどが行われる

統合環境

  • 複数のコンポーネントを統合し、システム全体の動作を確認する環境
  • UIテストやAPIテストなど、より広範囲なテストを実行
  • モニタリングツールを導入し、システムの挙動を監視

プレプロダクション環境

  • 本番環境に近い環境で、最終的な品質確認を行う環境
  • パフォーマンステストや負荷テストなど、非機能的なテストが中心
  • ユーザー受け入れテスト(UAT)を実施し、ビジネス側の視点からシステムを評価する。

本番環境

  • システムが実際に稼働する環境
  • モニタリングツールを導入し、システムの異常を検知し、迅速に対応する必要がある
  • カナリアリリースやブルーグリーンデプロイメントなどの手法を用いて、リスクを最小限に抑えながら新機能を導入
  • A/Bテストなどのベストプラクティステスト
2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?