E2EのフロントテストでPlaywrightを使うことを決めた話 #11. 自分のサービスの操作マップを作る

Playwright のテスト設計と運用で最大効果を出すための方法として「操作マップ」を作るといいでしょう。

操作マップって何？

・どんなページがあるか ・どんな導線で遷移するか ・どの UI 操作が主要導線なのか ・どの部分が壊れやすいか

これらの視覚的 & 構造的にまとめた地図の事。 テストの優先順位を決めるための“サービスの攻略本”と考えてもいいでしょう。

操作マップは作った方がいいの？

テスト自体も開発本業の脇役的な作業出し、ドキュメント記述もあるし、その他にも色々と対応するべき事があるのに、 操作マップまで作るなんて作るのめんどくさいと感じる人もいるでしょう。 でも、操作マップは確実に作った方がいいです。 だって、E2E テストがそもそも実行スピードが遅いから全部を網羅しようとすると破綻することが多いんです。 なので、テストを充実させたいと思ったら、確実に操作マップを用意しておいた方がいいんですよね。 どの部分が最重要なのかを把握して、優先順位を決めることができ雨量になるでしょう。 また、「スモーク / 詳細」を切る基準が明確になリマス。 あと、POM（PageObject）の設計にも役に立ちます。

・どのページをクラス化するべきか ・どこに共通 UI コンポーネントがあるか ・複雑な UI はどこか

前もって把握しておくとクラス設計がめちゃくちゃ楽になるんです。 それから、サービスの“壊れやすい箇所”がわか李やすくなるんですよ。

・動的リスト ・フォーム入力の多い画面 ・モーダル開閉 ・認証 ・決済導線

これらを事前にマップ化＝テストの数が最適化されること間違いなし！

操作マップのメリット

E2E の数が無駄に膨らまない

戦略的な減らし方ができる。

テスト設計が 10 倍速くなる

どのページで何をテストすべきか瞬時にわかる。

新機能追加時の判断が簡単

「この新機能はスモーク行き？詳細行き？」がマップを見るだけで判断可能。

POM が破綻しない

なんとなくクラスを切ると崩壊するが、操作マップがあると適切なページ構成になる。

操作マップの作り方

便利に思えてきた操作マップですが、実際にどういう風に作ればいいのか、サンプルを用いて解説します。

1. 全ページをリストアップする

・ログイン ・ダッシュボード ・ユーザー一覧 ・ユーザー詳細 ・ユーザー編集 ・設定 ・メール送信画面

最初は見えている部分だけでもいいので、サイトマップを作ってみましょう。

2. ページ同士の遷移を線で結ぶ

これらのページがどういうふうに繋がっているかを明示することが重要なので、下記のように繋がりを線で繋いでみましょう。 ログイン → ダッシュボード → ユーザー一覧 → ユーザー詳細 → ユーザー編集 ↘ 設定 遷移図のような、階層分けをすると、よりシステムの全体像が掴みやすくなります。 ログイン └ ダッシュボード ├ ユーザー一覧 │ └ ユーザー詳細 │ └ ユーザー編集 └ 設定

3. 各ページの主要UI操作を書き出す

例えば“顧客一覧”なら以下のような項目を書き出します。

・検索バー入力 ・ソート ・行クリックで詳細へ ・ページネーション ・削除（モーダル confirm）

4. 壊れやすい操作にマークをつける

・検索バー：複雑な Ajax → 壊れやすい ・モーダル confirm：ID 違いなど → 壊れやすい ・SPA のタブ UI：切替時にネットワーク待機 → 壊れやすい

E2E の対象にする優先度が高い箇所が明確になります。

5. スモーク/詳細の分類を作る

スモークに入れるべきは？

・ログイン → ダッシュボード ・顧客一覧が最低限表示される ・詳細画面が開く ・基本フォームの送信

6. POMと紐づける

以下のように操作マップのそれぞれの項目にPOMを紐付けます。

・LoginPage ・DashboardPage ・CustomerListPage ・CustomerDetailPage

総合サンプル

【ログイン（Smoke）】 └ Page: LoginPage └ 操作 - /login を開く - メールアドレス入力 - パスワード入力 - ログインボタン押下 └ 遷移 → ダッシュボード 【ダッシュボード（Smoke）】 └ Page: DashboardPage └ 操作 - 概要パネル表示確認 - メニューからユーザー一覧へ移動 └ 遷移 → ユーザー一覧 【ユーザー一覧（Smoke / Detail 混在）】 └ Page: UserListPage └ 操作（Smoke） - 一覧テーブルの表示チェック - ユーザー1件をクリック → 詳細へ └ 操作（Detail） - 検索フォームで絞り込み - ページネーション - 並び替え（名前/登録日など） └ 遷移 → ユーザー詳細 【ユーザー詳細（Detail）】 └ Page: UserDetailPage └ 操作 - 基本情報の表示確認 - 編集ボタンから「ユーザー編集」へ └ 遷移 → ユーザー編集 【ユーザー編集（Detail）】 └ Page: UserEditPage └ 操作 - フォーム入力 - バリデーション確認 - 更新 → 一覧へ戻る └ 遷移 → ユーザー一覧 【設定（Detail）】 └ Page: SettingsPage └ 操作 - アプリ設定項目の確認 - 通知設定の切り替え └ 遷移 → メール送信画面 or ダッシュボード 【メール送信画面（Detail）】 └ Page: MailSendPage └ 操作 - 宛先入力 - 件名入力 - 本文入力 - プレビュー - 送信 └ 遷移 → 完了画面 or ダッシュボード スモークと詳細は、太字、細字（または色違い）などで区別するといいでしょう。

あとがき

WebページにおけるE2E自動テストについて、数回に渡って解説して学習を進めてみましたが、実際にご自身のWEBサービス開発で使えるイメージが持てましたでしょうか？ 実際に自分でテストコードを書くもよし、GUIを使ったコードを流用するもよし。 とにかくE2Eテストは事前準備も含めて、めんどくさいモノなんです。 今回のように、操作マップを事前に作る工程などは、よほどしっかりと設計をしなければ、実際に運用フェーズまで持っていくことができなくなるでしょう。 でも、WEB開発における自動テストは、「やるかやらないか」ではなく、やらざるを得ない工程だとも思います。 どうしてもめんどくさいと思ってしまう人は、一度サービストラブルにあってみないとわからないかもしれませんね。 とにかく、歯を食いしばってでも、E2Eテスト始めてみませんか？