テストの安定性を向上させるには – MagicPodヘルプセンター

ここでは、テストの安定性を向上させたり、自動テストを簡単にするためのアプリ実装の工夫をご紹介します。

安定するロケータを設定する
いつ、誰が行っても成功するテストを目指す
「待機」コマンドを活用する
「条件分岐」コマンドを活用する
「失敗時のリトライ」機能を活用する
ユーザー視点のシナリオに基づくテストを作成する

1. 安定するロケータを設定する

ロケータとは、テスト時に操作対象のUI要素を特定するための文字列です。例えば、id、XPath、CSSセレクタなどが該当します。MagicPodでは、UI要素ごとにロケータが自動で設定されます。ユーザーは、MagicPodが提示する複数の候補の中からロケータを選び直したり、自分でロケータを追加・変更することも可能です。

テスト対象アプリをバージョンアップすると、UI要素が特定できなくなり、テストが失敗することがあります。
これは、HTMLなどの画面構成が変更され、従来のロケータでは要素を検出できなくなるためです。こうした失敗を防ぐには、画面構成の変化に左右されにくい「安定したロケータ」を設定することが重要です。

安定したロケータについては以下で解説します。

1-1. ユニークID

MagicPodでは、ユニークIDをロケータとして使用することを最も推奨しています。アプリ開発時に、各UI要素に対して他の要素と重複しない「一意なID（ユニークID）」を付与しておくことで、テスト時に要素を正確に特定できます。これにより、テストの安定性が大きく向上します。

ユニークIDの具体的な付与方法は、こちらでご確認ください。

既存のアプリにユニークIDを後から追加するには一定のコストがかかりますが、将来的なテストの安定運用に大きく貢献するため、導入をぜひご検討ください。

1-2. ユニークID以外のロケータ

ユニークIDの付与が難しい場合は、できるだけ変更に強いロケータを設定することが重要です。たとえば、以下画像のような<a>タグの要素に対してロケータを設定する場合、属性値やテキストの内容によって要素が一意に特定できる場合があります。そのような場合は、以下のような形式でXPathを指定すると効果的です。

//xxx[@yyy='zzz']

この形式では、タグ名（xxx）と特定の属性（yyy）およびその値（zzz）を組み合わせることで、安定したロケータを構成できます。

1-3. AIロケータはなるべく避ける

MagicPodでは、ロケータの候補としてAIロケータ（MagicPodが自動生成したロケータ）が表示されることがあります。ただし、AIロケータの使用は推奨されません。一部のコマンドではAIロケータが使用できない場合があり、またテストの安定性や再現性に影響を及ぼす可能性があるためです。

できる限り、ユニークIDや属性ベースのロケータなど、明示的で安定したロケータを使用してください。

2.いつ、誰が行っても成功するテストを目指す

安定したテストを作成するには、実行するタイミングや環境に左右されないことが重要です。実行タイミングや環境のせいでテストが失敗するものには以下のような例が挙げられます。

ECサイトの商品購入テストで、毎回同じ商品を購入した結果、在庫がゼロになり、購入不可の状態となってテストが失敗する
ユーザー登録で同じメールアドレスを繰り返し使用したため、「すでに登録済みです」というエラーが表示され、テストが失敗する

このような環境では、定期的な自動実行が難しくなります。「いつ、誰が実行しても成功するテスト」を実現するには、次のような環境整備が必要です。

2-1. クリーンな環境でテストを開始する

安定したテスト実行を実現するには、テスト開始前に毎回データベースをクリーンな状態にリセットすることが重要です。例えば、以下のような操作が挙げられます。

ECサイトでは、在庫状況をテスト開始時に初期化する
ユーザー登録が必要なサイトでは、既存のユーザーすべてをテスト開始時に削除する

このように毎回同じ条件でテストを実行することで、テストの再現性が高まり、結果のばらつきを防ぐことができます。データベースの初期化には、専用のWeb APIを用意し、テスト実行時にコマンドから呼び出す方法が有効です。

2-2. テスト同士の依存関係をなくす

安定したテストを実現するには、各テストが独立して実行できることが重要です。
あるテストが他のテストの実行結果やデータに依存している場合、一部のテストが失敗することで連鎖的に他のテストも失敗し、原因の特定やデバッグが困難になります。よくある依存の例としては以下のようなものが挙げられます。

ログイン処理を別のテストケースで実施している
前のテストで作成されたデータを次のテストで利用している
テスト実行の順番が固定でないとうまく動作しない

解決策として、必要な前提条件を各テストケースの中で毎回準備しましょう。MagicPodの共有ステップ機能を活用すれば、テストケースごとに必要な共通処理（例：ログイン処理やデータ初期化）を、ステップ一つで簡単に組み込むことができます。これにより、テストは順番に関係なく独立して実行可能となり、失敗の原因を個別に切り分けやすくなります。

2-3. ユニーク値生成を活用する

ユニーク値生成コマンドは、テストごとに異なるアカウントを作成する際などに便利です。例えば、ユーザー登録が必要なテストで毎回同じアカウントを使用していると、以下のような問題が発生する可能性があります。

アカウントがすでに登録済みのため、「このメールアドレスは使用できません」といったエラーが表示される
同一アカウントによる短期間での連続ログインが制限され、自動化テストがブロックされる

これらの問題を回避するには、現在時刻をもとに生成したユニークな値を保存コマンドを活用しましょう。
このコマンドを使えば、テスト実行ごとに異なる値を自動生成できるため、それをユーザーIDやメールアドレスなどに使用することで、毎回異なるアカウントでのテスト実行が可能になります。

2-4. テスト用にアプリケーションの実装を調整する

IoT家電などの外部機器との接続を含むテストでは、接続ステップが自動化の障壁となり、やむを得ず手動で対応しているケースもあるかと思います。しかしテスト用にアプリケーションの実装を一部調整することで、こうしたケースでも自動化が可能になります。

例えば、IoT家電用のスマートフォンアプリで「エアコンの電源を入れる」ステップがある場合、本来であれば実際に家電と通信して動作を確認する必要があります。しかしテスト用に、実際の通信処理をスキップし、代わりに通信成功を模したフラグを返すモードをアプリに実装すれば、外部機器なしでもテストが完結します。

このように、実環境を完全に再現せずとも、動作確認に必要な処理だけを残してアプリを調整することで、テスト自動化の範囲を広げることができます。

3.「待機」コマンドを活用する

MagicPodには、テストの安定性を高めるためのさまざまな待機コマンドが用意されています。

「待機」コマンドでは、「画面全体の描画が終わるまで待つ」や「UI要素が有効になるまで待つ」など、次のアクションに進む前に、必要な条件が満たされるまで待機するよう、明示的に指定することができます。また、「◯秒間待つ」コマンドで、任意の秒数待機させることも可能です。例えば、以下のような活用事例があります。

画像差分チェックの安定化

課題： ページの読み込みが遅く、十分に描画される前に「画像差分がないか確認」コマンドが実行され、不要な差分が検出されてしまう。
対処： 直前に「画面全体の描画が終わるまで待つ」コマンドを挿入することで、描画完了後にチェックが行われ、テストが安定。

UI要素のアクティブ化待ち

課題： アプリ起動直後、ボタンがまだアクティブでない状態で「タップ」コマンドが実行され、操作できずテストが失敗。
対処： 「UI要素が有効になるまで待つ」コマンドを追加することで、ボタンが操作可能な状態になってからタップを実行できるようになり、成功率が向上。

また「待機ポリシー」という設定項目から、問題が発生した際に待機する時間をテストケース全体に対して設定することも可能です。詳細はこちらのページに記載しております。

4. 「条件分岐」コマンドを活用する

MagicPodでは、特定の条件に応じて処理を分けることができる条件分岐コマンドを利用できます。このコマンドを使うことで、状況に応じた柔軟なテストの構築が可能になります。

例えば、以下のようなケースで条件分岐コマンドが有効です。

Googleの初回アクセス時のみ表示されるログインダイアログの処理
　→ ログインダイアログが表示されている場合のみ「閉じる」や「スキップ」操作を行う。
アプリ起動時に表示される権限付与ダイアログの対応
　→ ダイアログが表示された場合は「許可する」、表示されていない場合は処理をスキップ。
不定期に表示されるポップアップ広告の閉じる処理
　→ 広告が表示されている場合のみ「閉じる」ボタンをタップ。

5. 「失敗時のリトライ」機能を活用する

一時的なネットワークの切断やサーバーの不具合など、環境要因によって発生する一過性のテストの失敗は、完全に防ぐことが難しい場合があります。そのようなケースに備えて、MagicPodの「失敗時のリトライ」機能を活用することをおすすめします。

リトライ機能は、「一括実行設定」＞「詳細設定」＞「失敗テストのリトライ」で設定できます。有効にすることで、一時的な問題によるテスト失敗時に自動で再実行されるようになります。

リトライ回数は、極端に多くしても成功率が大きく改善する可能性は低く、恒常的な不具合を見逃す可能性もあるため、1回または2回の設定を推奨します。

6. ユーザー視点のシナリオに基づくテストを作成する

MagicPodによるE2Eテストは、ユーザーの操作フローに沿って、システム全体が期待通りに動作するかを検証するテストです。そのため、単体テストや結合テストとは目的が異なります。

E2Eテストは、「正常系のユーザーストーリー」に基づいたテストを中心に作成することをおすすめします。E2Eテストに、細かいUIの表示チェックや境界値テストなどを多く詰め込みすぎると、テストケースが複雑になり、保守性や安定性が低下します。これらの細かい検証は、単体テストや結合テストに任せるのが適切です。

また、異常系の検証（例：不正な値を入力した際にエラーが表示されるかなど）についても、単体・結合テストでカバーすることが望ましいです。E2Eテストで異常系を頻繁に実行すると、失敗要因が増えてしまい、テストの安定性が損なわれることがあります。

目次