共通の基盤となるアプリを、企業ごとにロゴ・配色・文言・利用できる機能・接続先などを変えて提供している場合（いわゆるマルチテナント／ホワイトラベルのアプリ）、企業ごとにテストケースを作るとテストケースの数が企業数に比例して増え、画面変更のたびに同じ修正を何度も行うことになります。
このページでは、1つのテストケースを全テナントで使い回し、テナントごとの違いは設定で吸収するための考え方とMagicPodの機能の使い方を紹介します。
※このページでは、カスタマイズして提供している1社ごとの単位を「テナント」と呼びます。
目次
- 基本方針
- テナントごとの違いを整理する
- テナントごとに一括実行設定を作る
- 共有変数とデータパターンの使い分け
- テナントによって変わらないロケーターを使う
- 共通の操作は共有ステップにまとめる
- テナントによって機能や画面の流れが違う場合
- どのテナントで、いつテストするか
- プロジェクトの分け方
- 運用ルールの例
1. 基本方針
- テストケースは全テナント共通で1つ作り、テナントごとに複製しません。
- テナントごとに違う値（URL、ログイン情報、表示される文言など）は、テストケースに直接書かずに共有変数として外に出します。
- テナントの切り替えは、テストケースではなく一括実行設定で行います（テナント1つにつき一括実行設定を1つ）。
こうしておくと、画面変更などでテストケースを直すときは1か所の修正で全テナントに反映され、新しいテナントを追加するときも一括実行設定を1つ追加するだけで済みます。
2. テナントごとの違いを整理する
テストケースを作り始める前に、テナントによって何が違うのかを洗い出しておくことをお勧めします。違いの種類によって、使う機能が変わります。
| テナントごとの違い | 例 | MagicPodでの対応 |
|---|---|---|
| 接続先・URL | テナントごとのサブドメイン、APIの接続先 | ブラウザ：ベースURL／モバイル：テナントごとのアプリファイル、アプリ起動時引数 |
| ログイン情報 | テナントごとのテスト用アカウント | 共有変数（パスワードはシークレット共有変数） |
| 表示される文言・金額・企業名 | 画面タイトル、サービス名、手数料 | 共有変数を使って確認する |
| ロゴ・配色などの見た目 | テーマカラー、ロゴ画像 | 見た目の確認は代表テナントに絞る（後述） |
| 機能の有無 | ある機能が一部のテナントだけで有効 | ラベルで実行対象を分ける／条件分岐 |
| 画面の流れ | 利用規約の同意画面が一部のテナントだけで表示される | 条件分岐、または共有ステップを分ける |
3. テナントごとに一括実行設定を作る
一括実行設定の「詳細設定」タブで、テナントごとに次の項目を設定します。設定名にはテナントが分かる名前を付けておくと管理しやすくなります（例：「10:テナントA_ステージング」）。
共有変数
テナントごとに違う値を共有変数として登録し、テストケースからは ${変数名} で参照します。
| 変数名（例） | テナントA | テナントB |
|---|---|---|
| TENANT_NAME | テナントA | テナントB |
| LOGIN_ID | tenant-a-test@example.com | tenant-b-test@example.com |
| LOGIN_PASSWORD（シークレット） | **** | **** |
| SERVICE_TITLE | 〇〇Pay | △△ウォレット |
- パスワードやAPIトークンは、シークレット共有変数にしてマスクしてください。
- 変数名は全テナントで揃えてください。テナントによって変数名が違うと、テストケースを共通化できません。
参考：変数の活用
ブラウザテストの場合：ベースURL
テナントごとにドメイン・サブドメインが違う場合は、一括実行設定の「ベースURL」にテナントごとのURLを設定し、テストケースの「URLを開く」ではルート相対アドレス（例：/login）を使います。
参考：テストの実行環境を切り替える（ドメインを切り替えてテストケースを使用する）
※ベースURLの欄には変数を使えません。URLのパス部分でテナントを区別している場合（例：https://example.com/tenant-a/）は、「URLを開く」で ${TENANT_PATH}/login のように共有変数をURLに含めてください。
モバイルアプリテストの場合：アプリファイル・アプリ起動時引数
- テナントごとに別のアプリ（バンドルID・パッケージ名が別）としてビルドしている場合は、一括実行設定ダイアログでテナントごとにテスト対象のアプリを指定します。
- 1つのアプリの中でテナントを切り替えられる場合は、アプリ起動時引数やアプリ環境変数でテナントを渡せるよう、開発チームに相談するのも有効です。
APIから実行する場合
CIなどからテナントを切り替えて実行したい場合は、一括実行設定番号を指定しつつ共有変数だけを上書きすることもできます。
参考：一括実行設定番号を使いながら一部設定を上書きしてテストを実行したい
4. 共有変数とデータパターンの使い分け
1つのテストケースを入力データを変えて繰り返し実行する「データパターン」も、テナントごとの違いを扱うのに使えます。共有変数とは得意なことが違うため、次のように使い分けるのがお勧めです。
| 共有変数 | データパターン | |
|---|---|---|
| 向いている値 | テナントごとに変わる値（URL、ログイン情報、表示名など） | テナントに関係なく試したい入力のバリエーション（支払い方法、金額など） |
| 値を設定する場所 | 一括実行設定（その設定で実行するすべてのテストケースで使われる） | テストケースごと |
| 実行のされ方 | 一括実行設定に登録した1テナント分の値でテストする。別のテナントは別の一括実行設定で実行する | 1つのテストケースが、登録したパターンの数だけ繰り返し実行される（例：3パターンなら3回） |
データパターンが向いている場面
-
同じテナントの中で、入力を変えて確認したい場合
支払い方法（クレジットカード／銀行口座）や金額（上限額ちょうど／上限額超え）の組み合わせなど、テナントに関係なく試したいパターンはデータパターンにします。テナントの値（共有変数）と同じテストケースの中で組み合わせて使えます。 -
ブラウザテストで、全テナントに同じ軽い確認をまとめて行いたい場合
テナントの違いがURLとログイン情報だけであれば、データパターンの1行を1テナントにして、1つのテストケースで全テナントを続けて確認できます（例：各テナントのログイン画面が開き、ロゴが表示されるか）。また、特定のテナントだけを実行することもできます。一括実行設定の「実行対象」タブで「テストケース番号を指定」を選び、「テストケース番号[データパターンの番号]」の形で指定すると、そのデータパターンだけが実行されます。たとえば、テストケース番号3のデータパターンの2番目にテナントBの値を設定している場合、「3[2]」と指定すると、テナントBの分だけが実行されます。
データパターンにテナントの情報を持たせるときの注意
- データパターンはテストケースごとに設定するため、テナントの情報を多くのテストケースのデータパターンに書くと、テナントの追加やログイン情報の変更のたびに、すべてのテストケースを直すことになります。複数のテストケースで使うテナントの情報は、共有変数にまとめてください。
- パスワードなどの値はデータパターンに書かず、シークレット共有変数を使ってください。
- モバイルアプリでテナントごとにアプリが別の場合、テスト対象のアプリは一括実行設定で決まるため、テナントの切り替えは一括実行設定で行ってください。
5. テナントによって変わらないロケーターを使う
テナントごとに文言やデザインが違うアプリでは、テキストや画像をもとにしたロケーターはテナントを切り替えた途端に失敗します。
- 開発チームに、全テナントで共通のユニークID（Webなら
idやdata-testid、モバイルなら accessibility identifier / resource-id など）を付けてもらうのが最も効果的です。 - テキストを含むロケーターを使う場合は、
${SERVICE_TITLE}のように変数付きロケーターにすることで、テナントごとの文言に対応できます。
6. 共通の操作は共有ステップにまとめる
ログイン、ホーム画面への移動、決済の入力など、全テナントで共通の操作は共有ステップにします。共有ステップの中でも共有変数（${LOGIN_ID} など）を使えば、1つの共有ステップで全テナントのログインができます。
テナントによって手順が大きく違う部分（例：利用できる支払い方法がテナントで異なり、入力画面の流れが違う）は、「支払い（クレジットカード）」「支払い（銀行口座）」のように共有ステップを分けておくと、テストケースが読みやすくなります。
参考：共有ステップの活用
7. テナントによって機能や画面の流れが違う場合
機能そのものが一部のテナントにしかない場合：ラベルで分ける
その機能のテストケースに機能名のラベル（例：「機能_ポイント払い」）を付け、その機能があるテナントの一括実行設定だけで、ラベルを実行対象に含めます。テストケースの中でテナントを判定するより、何がどのテナントで実行されているかが一覧で分かりやすくなります。
同じテストケースの一部の手順だけが違う場合：条件分岐
共有変数でテナントの設定（例：FEATURE_POINT=on）を持たせ、「変数の値が一致する場合」コマンドで処理を分けます。
条件分岐が増えすぎるとテストケースが読みにくくなるため、分岐が多くなる場合はテストケースを分けることも検討してください。
参考：条件分岐の活用
8. どのテナントで、いつテストするか
テナント数 × テストケース数を毎回すべて実行すると、実行時間とクラウド端末の利用枠を大きく使います。変更の内容に応じて実行範囲を分けるのがお勧めです。
| タイミング | 実行するテナント | 実行するテストケース |
|---|---|---|
| 基盤（共通部分）の変更時・日次 | 代表テナント（有効な機能が最も多いテナントなど）1〜2個 | 全テストケース |
| 特定テナントのカスタマイズ変更時 | 変更したテナントのみ | 全テストケース |
| リリース前 | 全テナント | ログイン・主要な決済の流れなどのスモークテスト |
- ロゴや配色などの見た目の確認（画像差分チェックなど）は、テナントごとに期待値が変わるため、代表テナントに絞るか、必要なテナントだけで行うと管理しやすくなります。
- スケジュール実行を使う場合は、テナントごとの一括実行設定を時間をずらして登録すると、クラウド端末の同時実行数を超えにくくなります。
9. プロジェクトの分け方
基本は1つのプロジェクトにまとめることをお勧めします。共有ステップや共有UIは同じプロジェクトの中でしか使えないため、テナントごとにプロジェクトを分けると、共通部分の修正をプロジェクトの数だけ行うことになります。
ただし、次のような場合は、プロジェクトを分けることも検討してください。
- カスタマイズが大きく、画面の構成がほとんど共通していない
- テナントごとにテストを担当するチームが分かれており、メンバーの権限を分けたい
10. 運用ルールの例
テナントの数が増えるほど、一括実行設定やラベルが増え、誰がどのテナントのテストをどう管理しているかが分かりにくくなります。テナントを追加したり、テストケースを直したりするときに迷わないよう、次のようなルールを事前にチームで決めておくことをお勧めします。
- 一括実行設定名・ラベル名にテナント名や機能名を入れる命名規則を決める
- テナントを追加するときの手順をまとめておく（一括実行設定の追加、共有変数の登録、機能ラベルの確認、テスト用アカウントの用意）
- テナント固有の不具合が見つかったときに、テストケースを共通のまま直せるか（共有変数・ラベルで対応できるか）を先に検討する