E2Eテスト、何から書く？小さな業務システムで最初に選ぶ3つの利用経路

テストを増やしたい。でも画面もボタンも多く、どこから始めればよいか分からない。業務システムなら、画面の数ではなく「止まると仕事が終わらない流れ」から選ぶ方法があります。

最初の候補は、登録して使う、権限を分ける、失敗から戻る、の3つです。E2Eは、利用者の操作から一連の結果までを確かめるテストです。この記事は架空の申請システムを使う選び方で、どのシステムも3本だけで十分という意味ではありません。

1つ目は、登録した内容を別の画面で使う経路

申請フォームを送るだけで終えず、一覧で探し、詳細で同じ内容を確認します。ボタンの色や内部の関数が呼ばれたかより、利用者が仕事を完了できたかを見ます。保存の結果が次の画面へ反映されない不具合を見つける狙いです。

経路	入力と期待結果
登録して使う	検証用の申請を登録し、一覧と詳細で同じID・内容を確認
権限を分ける	本人と別担当のアカウントで、閲覧できる範囲を確認
失敗から戻る	保存エラー時に完了表示せず、修正・再操作できるか確認

管理者で動いたからといって、一般利用者の権限が正しいとは限りません。利用者Aの申請を利用者Bが見られないなど、重要な境界を試します。URLを直接開く操作も対象です。画面でリンクを隠すだけでは、データへのアクセスを止めた確認になりません。

E2Eで全権限の組み合わせを網羅するのが重い場合は、権限制御を別のテストでも確かめ、代表的な利用経路をE2Eでつなぎます。実顧客のデータを使わず、毎回用意できる検証用のデータと利用者を使います。

通信が失敗したとき、入力が消える、成功したか分からない、再操作で重複する。こうした場面は業務での問い合わせにつながります。検証環境で失敗条件を作り、成功表示、保存状態、再操作をセットで確かめます。本番で障害を起こして試す必要はありません。

テスト1が登録したデータをテスト2が探す構成では、テスト1の失敗で別の問題まで連鎖します。Playwrightの公式ガイドは、利用者に見える振る舞いとテストの独立性を重視しています。各テストで必要な前提を用意し、ほかのテストの成功を待たない設計にします。

経路名：申請を登録し、詳細で確認する
前提：権限のある検証用利用者、固有の申請ID
操作：入力 → 送信 → 一覧 → 詳細
確認：ID・内容・保存件数が一致する
片付け：このテストが作ったデータだけを削除
失敗時の記録：操作・画面・環境・対象バージョン

毎日使う登録、月1回でも締めに必要な処理、他人の情報へ触れる権限など、利用頻度だけでは順番が決まりません。まず失敗の影響を話し合い、自動化しやすい経路から1本作ります。文言変更に合わせて毎回壊れるなら、利用者の結果より画面の細部に依存していないか見直します。

3経路が安定してから、実際に起きた不具合と重要な機能変更を追加します。テスト本数を増やすことより、変更したときに何を守れているかを、開発者以外にも説明できる状態を目指してください。

2026年11月2日確認。本文の例・図・ひな型は本記事用に作成したものです。以下は、設計や事例の背景として参照した一次資料です。