本記事では、Webアプリのテストツールとして利用していたPlaywrightからMagicPodへ移行した背景や、移行に伴う考慮点、実際に運用してみた結果についてまとめます。
移行した理由
- 開発スタイルの変化
開発当初はフロントエンドとバックエンドを別メンバーで開発を進めており、フロントエンドのテストはMockを活用していました。しかし、保守開発フェーズに入ると各開発メンバーがフロントエンドとバックエンドを両方担当するようになりました。そのため、E2Eテストをフロントエンドとバックエンドを連携して実環境に近い形で実施する必要がありました。
- メンテナンス性
上記の開発スタイルの変化やテストの複雑化に伴い、Mockデータが実際のAPIの挙動との乖離が発生しました。そこで、Mockを使用せずにバックエンドと連携したE2Eテストを実施し、かつノーコードでテストを作成できるMagicPodを採用することにしました。
MagicPodに期待していたこと
MagicPodへ移行するにあたって、期待したことは以下のとおりです。
-
ノーコードによる保守性向上
- Playwrightではコードの管理が必要でしたが、MagicPodのノーコード環境を活用することで、バックエンドエンジニアでもテストの作成・修正ができるようになると考えました。
- これにより、バックエンドエンジニアもテストケースを作成しやすくなり、フロントエンド・バックエンドの共同開発がスムーズになることを期待しました。
-
AI修正や画像比較機能の活用
移行するにあたって考慮したこと
構成の違い
Playwrightではページ単位でのテスト実行が中心であり、特定のページの動作を個別に検証する構成になっていました。
一方、MagicPodではシナリオベースの動作検証がしやすく、ユーザーの操作フロー全体を通したテストを直感的に作成できる点が大きな違いと考えます。
Playwrightの構成
Playwrightでは、基本的に各画面単位でテストを作成していました。各テストは独立しており、ページ単位での動作検証を主に行っていました。
ディレクトリ構成
tests/
├── login.spec.ts
├── dashboard.spec.ts
├── settings.spec.ts
MagicPodの構成
一方MagicPodでは、画面遷移を含めたテストシナリオを直感的に構築できることを考慮し、シナリオごとにテストケースを管理する方針を採用しました。これにより、ユーザーの操作フロー全体を通した包括的なテストを実施できるようになりました。
メンテナンス性の向上策（共通ステップの活用）
Playwrightでは関数や共通ライブラリを作成することで、重複コードを削減していました。一方、MagicPodでは 「共通ステップ」機能を活用することで、メンテナンス性を向上させました。
Playwrightの場合
Playwrightではhelpers.tsやutils.tsに共通関数を定義します。以下のコードはログイン処理を関数化したものです。
async function login(page, username, password) {
await page.fill('#username', username);
await page.fill('#password', password);
await page.click('#login-button');
}
- メリット
- コードの再利用性が高まる
- デメリット
- 関数の管理が増える
MagicPodでの共通ステップ活用
一方MagicPodではログイン処理などを「共通ステップ」として登録し、複数のテストケースで利用することができます。UIが変わっても、共通ステップを一箇所修正すればすべてのテストケースに適用が可能となります。
- メリット
- 保守性が向上し、ノーコード環境でも柔軟に対応可能
- デメリット
- 共通ステップの管理が煩雑になる可能性があるため、適切な命名や管理ルールが必要
実際に運用してみて
ノーコードによる保守性について
MagicPodのノーコード環境により、視覚的にテストを編集できることで、保守性が向上しました。特に、テストケースのフローを画面上で直感的に確認できるため、コードベースの管理と比べて変更の影響範囲を把握しやすくなっています。
さらに、ノーコード化により学習コストが大幅に削減され、初学者や新規参入メンバーでも行いやすくなりました。これによりテスト運用の属人化を防ぎ、チーム全体でのメンテナンス性の向上が期待されます。
現時点では定量的な評価はできていませんが、Playwrightのコード管理時と比べてテスト修正時の心理的な負担が減り、テストの更新がスムーズに行えるという感触を得ています。
AI修正や画像比較機能を活用した結果
MagicPodのAI修正機能により、UIの軽微な変更時に自動で修正候補が提示されるため、手作業での修正の手間が軽減されました。これにより、テストのメンテナンス性が向上し、特に頻繁なUI更新があるフェーズでは修正作業の負担が軽減されました。
また画像比較機能により、意図しないデザイン変更を素早く検知できるようになりました。従来のDOM要素比較では検出が難しかったケースにも対応でき、UIテストの精度が向上しています。
さらに画像比較機能は、画像単位で比較対象の除外範囲や許容する不一致率も設定できるため、柔軟なテストが可能となっています。
定期的なテストを自動実行する仕組み
MagicPodの一括実行機能を活用し、CI/CDパイプラインと連携して定期的なE2Eテストを自動実行する運用を開始しました。GitLab CIとの統合により、勤務開始前に全テストを自動実行して結果をレポートとして通知する仕組みを構築しました。
この運用により、手動実行の手間を削減しつつ、継続的なテスト実行による品質の監視が可能になりました。また、特定のテストのみを選択して実行できる機能を活用することで、変更の影響範囲に応じた効率的なテスト運用が実現できています。
安定したロケータの選定
上記のようなメリットの一方で、安定したロケータの選定やコードへのdata-testidの設定など、定期テストを安定して稼働させるための工夫も必要であることが分かりました。
ロケータとは
まとめ
MagicPodへの移行により、ノーコード環境でのテスト管理が可能になり、学習コストの削減やメンテナンス性の向上が実現しました。AI修正機能や画像比較機能の活用により、UI変更時の対応が容易になり、CI/CDと連携した自動テストで継続的な品質監視も強化されました。一方で安定したロケータの選定など、引き続き改善すべき課題も見えてきました。