6.1 テスト自動化プロジェクトを定義する

テスト自動化は「ソフトウェア開発」である

テスト自動化プロジェクトを成功させるための最大の前提は、それを 「ソフトウェア開発プロジェクト」 として扱うことです。

しっかりとしたアーキテクチャや設計を持たずに自動化スクリプトを作り始めると、メンテナンスコストが膨れ上がり、最終的には目標とする投資収益率（ROI）を達成できない「使えないツールセット」になってしまいます。テスト自動化のコードも、本番のコードと同様に、設計の文書化、コードレビュー、コンポーネントテストを実施する必要があります。

テクニカルテストアナリスト（TTA）は、自動化ツールの選定（または自社開発の決定）、インターフェース（アダプター）の開発、スケジュールと保守時間の確保、そしてテストアナリストへのトレーニングなど、自動化基盤の確立において中心的な役割を担います。

自動化アプローチの選択

テストの自動化を設計する際、TTAはシステムとどのように通信し、データをどのように管理するか（アーキテクチャ）を決定しなければなりません。

1. GUI、API、CLIによる自動化

テストの自動化はGUI（画面操作）に限定されるものではありません。GUIはソフトウェアの進化に伴って変更されやすいため、GUIの「キャプチャ / プレイバックツール」（操作を録画して再生するツール）で作られたスクリプトは、画面のレイアウトが変わるたびに動かなくなるという脆さ（メンテナンスの負担）を抱えています。そのため、API（アプリケーション・プログラミング・インターフェース）やCLI（コマンドラインインターフェース）などの、より安定したバックエンド層での自動化を検討・併用することが重要です。

2. データ駆動アプローチ (Data-Driven Testing)

テストスクリプトの中に直接「テストデータ」を書き込んでしまうと、値が異なるだけの似たようなスクリプトを大量に作ることになり、非効率的です。

データ駆動アプローチでは、スクリプトの「処理ロジック」と、入力する「テストデータ」を完全に分離します。データ（入力値と期待される結果）は外部のスプレッドシートやデータベースに持たせ、1つのスクリプトがそのデータを次々と読み込んで実行ループを回すように設計します。これにより、プログラミングスキルを持たないテストアナリストやビジネス担当者でも、スプレッドシートのデータを編集するだけでテストケースを追加できるようになります。

3. キーワード駆動アプローチ (Keyword-Driven Testing)

データ駆動をさらに一歩進め、テストデータに対する「アクション（動作）」もスクリプトから分離する手法です。

人間が直感的に理解できる「高水準言語（キーワード）」を定義してテストケースを記述します。

ビジネスプロセスのキーワード（高レベル）: 「Login」、「CreateUser」、「Cancel_Order」など。
UI操作のキーワード（低レベル）: 「ClickButton」、「SelectFromList」など。

テストアナリストはプログラミングを意識せず、これらのキーワードとデータを並べてテストケースを設計します。TTA（または自動化エンジニア）は、ツールがこれらのキーワードを読み取った際に、背後で実際のスクリプト（モジュール化された関数）が呼び出される仕組み（自動化フレームワーク）を構築します。

自動化を安定稼働させるための重要ポイント

スクリプトが途中で止まったり、次のテストに悪影響を与えたりしないよう、以下の2点を設計に組み込む必要があります。

1. ソフトウェア故障への対処 (Error Handling)

テスト中に予期せぬエラーやクラッシュが発生した場合、自動化スクリプトがフリーズしてしまっては意味がありません。「エラーをログに記録して次のテストケースへ進むべきか」「テストを強制終了するべきか」「ダイアログボックスを自動で閉じてリトライするべきか」など、故障発生時のスクリプトの振る舞いをあらかじめプログラミングしておく必要があります。

2. システムの状態の考慮 (State Management)

テストを繰り返し何度も実行できるようにするためには、各テストケースの開始時と終了時に「システムをあらかじめ定義された初期状態に戻す（リセットする）」ことが不可欠です。テスト内で作成したダミーデータをテスト終了時に自動で削除したり、データベースのステータスを元に戻したり、確実にログアウト処理を行うといったクリーンアップ（Teardown）の仕組みを自動化フレームワークに組み込みます。

ビジネスプロセスのモデリングにおける注意点

キーワード駆動アプローチを採用する場合、キーワードの「粒度（細かさ）」のバランスを取ることが課題となります。

細かすぎるキーワード（例：「ClickButton」）を多用すると、あらゆる画面操作に対応できる反面、UIが変更されたときに多数のテストケースを修正する手間が発生します。
大きすぎる（集約された）キーワード（例：「複数レコード一括作成」）は、テストを書くのは簡単ですが、自動化スクリプト側の実装やメンテナンスが極めて複雑になります。

TTAは、プロジェクトの成長に合わせて新しいキーワードを追加したり、変更したりするプロセスをチーム内でルール化し、運用していくことが求められます。