PlaywrightでAIのE2Eテストをレビューする：3操作の計画から失敗分析まで

AIが作った画面テストが成功しても、利用者に必要な動作を確認しているとは限りません。「ボタンがある」だけのテストと、「押した後に正しいデータが残る」テストでは確認できることが違います。期待する結果を先に文章で決め、生成されたテストと照合しましょう。

Playwrightの公式資料では、計画を作るplanner、テストを作るgenerator、失敗したテストを扱うhealerという役割が説明されています。導入手順は利用するAIツールとPlaywrightの版で確認してください。この記事は新しい依存の導入よりも、出力の妥当性を判断する練習を中心にします。［出典1］

教材の仕様をAIに渡す前に固定する

架空のTodoアプリに「タスク名」入力欄と「追加」ボタンがあるとします。入力を追加すると一覧に残り、空白だけの入力は拒否され、完了にすると未完了一覧から外れます。これは演習の仕様であり、実在アプリの挙動や本番テストの結果ではありません。

操作	事前条件	期待結果	成功と誤認しやすい確認
タスクを追加	空の一覧	指定の名前が1件追加され、入力欄は空になる	入力欄へ文字を入れただけ
空白だけを追加	空の一覧	追加されず、入力エラーが分かる	ボタンが表示されているだけ
完了へ変更	未完了が1件	そのタスクの状態が変わり、未完了表示から外れる	チェックボックスを押しただけ

表示文言やデータの初期化方法も決めます。前のテストが残したデータを次が使うと、単独実行では成功しないテストになり得ます。専用の試験環境と架空データを使い、実利用者のタスクは変更しない設計にします。

計画に、操作と期待結果の両方を書いてもらう

教材Todoの3操作について、事前条件、操作、期待結果、後片付けをMarkdownで整理してください。仕様にない成功条件を追加せず、空白入力の異常系も含めてください。各テストを単独で実行できるよう、初期データと初期化手順を明記してください。

生成前に人が計画を見ます。追加操作しかないなら、残り2操作を足します。「保存される」仕様なのに画面表示だけを確認しているなら、再読込後に確認する必要があるかを決めます。仕様をここで変える場合は、テスト計画だけでなく仕様書も更新してください。

生成されたコードを計画と一対一で対応させる

次は教材の「追加」だけを示すコード例です。URL、ラベル、一覧の役割、初期化は実際の教材環境へ合わせます。このまま未知のアプリに貼って実行できるサンプルという意味ではありません。

import { test, expect } from '@playwright/test';

test('タスク追加後に一覧と入力欄を確認する', async ({ page }) => {
  await page.goto('/');
  const input = page.getByRole('textbox', { name: 'タスク名' });
  await input.fill('教材を読む');
  await page.getByRole('button', { name: '追加', exact: true }).click();
  await expect(page.getByRole('listitem').filter({ hasText: '教材を読む' }))
    .toHaveCount(1);
  await expect(input).toHaveValue('');
});

ページの別の場所にも同じ文字があるなら、確認対象を実際の一覧へ絞ります。一覧項目が増えたことだけでは、保存や再読込まで確認したことにはなりません。何を確認したテストなのか、名前とassertionを一致させます。Playwrightの公式ベストプラクティスも、利用者から見た挙動や安定したロケーターの考え方を説明しています。［出典2］

失敗したら、アプリ・テスト・環境のどこを直すか判断する

失敗の例	先に調べること	採用してはいけない修正
追加後に入力が残る	仕様はクリアか。アプリがクリア処理をしているか	入力欄の確認だけ削除する
同名タスクが2件ある	初期化漏れ、二重送信、ロケーターの範囲	1件という条件を無条件で2件へ変える
空白入力が追加される	アプリの入力検証と計画の一致	異常系のテスト全体をskipする
対象ボタンが見つからない	ラベル変更、画面遷移、環境の起動状態	別のボタンをクリックして成功扱いにする

AIの修正案には、失敗原因、変更するファイル、残す期待結果を添えてもらいます。公式のhealerの説明にも、機能が壊れていると判断した場合にskipとなることが示されています。したがって、最後の画面が緑でもskipされた重要ケースがないか確認が必要です。［出典1］

テストが成功した後にも差分を見る

計画にある3操作が、実行対象として残っている。
期待結果のassertionが削られていない。
skip・条件付き実行・再試行の変更理由を説明できる。
初期化と後片付けが架空データだけを対象にする。
失敗の修正で、アプリの仕様や権限を勝手に変えていない。
単独実行とまとめた実行で、データの依存がないか確認した。

個別適用や説明の拡張時に確認する事項：3操作で成功しても、アプリ全体の品質や安全性の保証にはなりません。次に追加するのは、実際の利用者が困る入力や重要な操作です。CIで実行する仕組みと、テスト内容が正しいことは別の確認として扱いましょう。

出典

Playwright：Test Agents。planner・generator・healerの役割と出力。
Playwright：Best Practices。テスト対象、ロケーター、テストの独立性。
Playwright：Assertions。期待結果の確認に使うAPI。