Playwrightではじめる UI自動テスト入門 〜自動化の第一歩と、 これからのAI活用を一緒に考える〜 日本仮想化技術株式会社 VirtualTech.jp 2025/11/05 1 

● テストとは、「想定どおりに動くことを確かめること」 ● 開発では、コードを書くだけでなく「意図した通りに動くか」を確認する作業が必要 ● テストは品質を担保するためのフィードバック手段 ● 手動でも自動でも、「想定 → 実行 → 確認 →修正」のサイクルは同じ 2 そもそも「テスト」とは？ 

テストの種類 3 テスト種別 目的 主な範囲 例 単体テスト 小さな関数・ロジックが正しいか コードレベル 計算関数、バリデーション 統合テスト モジュール同士が正しく連携するか システムの一部 API通信、DB接続 E2E/UIテスト ユーザー操作が期待通り動くか 画面レベル フォーム入力、ボタン動作 

4 

品質の問題 ● 理想 ○ ユーザーがボタンを押した時に検索結果が画面に表示される ● よくない ○ ユーザーがボタンを押して ■ (A)画面表示されるが件数が少なかったり、意図した内容ではなかった場合 ● 不満はあるものの、認識齟齬の可能性も考えられ強く言われにくい(50:50状態) ● テストをやってなくてもボタンが押せるだけで減点は大きいが評価は30点〜 ■ (B)なんの反応もなく、一覧が真っ白で何も表示されていない場合 ● 「開発チームは何をやってるんだ！ちゃんと確認したのか！(激昂)」(0:100状態) ● どんなに単体や結合テストをやったとしても、ボタンが押せなければ評価は0点 ※点数にあまり深い言いみはありません 5 

「テストピラミッド」と「アイスクリームコーン」モデル テストピラミッド ● 理想的な形と言われているモデル ● 単体テストの比率が大きく、E2Eテストが 少ない状態 6 アイスクリームコーン ● アンチパターンと言われているモデル ● E2Eテストの比重が多いく、コストや時間 がかかる状態 

「テストピラミッド」と「アイスクリームコーン」モデル 7 

「テストピラミッド」と「アイスクリームコーン」モデル 8 一気に「テストピラミッド」モデルで実現できたら理想的ですが、 理想を目指して0点のリスクを取るより、悪くても30点を目指しつつ、目指すは理想的な形に 

今回は、E2Eテストから Playwrightを使って自動テストを やってみよう 9 

Playwrightとは ● Microsoftが開発するオープンソースのE2Eテストフレームワーク ● Chromium / Firefox / WebKit など複数ブラウザ対応(クロスプラットフォーム) ● Node.jsベースで、TypeScript / JavaScriptやPythonなどから利用可能(クロスランゲージ) ● 安定した自動待機・スクリーンショット・レポート機能を標準搭載 公式ドキュメント：https://playwright.dev/ 10 

セットアップしてみよう ● Node.jsが入っていれば、コマンド一つで導入 ○ npm init playwright@latest ● 対話形式でブラウザ・言語・例の選択 ● 初期構成：tests/, playwright.config.ts, package.json 11 

テストの基本構成を理解する ● Playwright Testを利用（@playwright/test） ● テスト単位はtest('説明', async ({ page }) => { ... })関数で定義 ● pageオブジェクトでブラウザ操作を抽象化 ○ await page.goto('https://example.com') ● expect()で結果を検証 ○ expect(await page.textContent('h1')).toBe('Hello') 12 

テストを実行してみよう ● 実行：npx playwright test ● 結果レポート：npx playwright show-report ● 並列実行・ブラウザ選択・ビデオ記録もワンコマンド 13 

UIモードでテストの動きを見てみよう ● コマンド： ○ npx playwright test --ui ● 専用のGUIが起動し、テストの実行・再実行・結果確認が可能 ● 実際のブラウザ操作の様子をそのまま観察できる ● テストのデバッグや、初学者が動作を理解するのに最適 ● 途中でブレークポイントやステップ実行も可能 14 

UI自動テストを書いてみる 15 

ログイン画面を題材にしてみよう ● ログイン画面を題材に、典型的なUI操作をテスト化 ● 操作 → 入力 → 結果確認 の基本パターン ● コード例（簡潔版）： test('ログイン成功のテスト', async ({ page }) => { await page.goto('https://example.com/login'); await page.fill('#username', 'testuser'); await page.fill('#password', 'password123'); await page.click('button[type="submit"]'); await expect(page.locator('.welcome')).toHaveText('ようこそ testuser さん'); }); ● ポイント： ● goto: ページを開く ● fill / click: 操作を実行 ● expect: 結果を検証 16 

テストを整理して続けやすくする 17 ● describe：関連するテストをまとめて構造化できる ● beforeEach：各テスト前の共通処理を定義 ● test：個々のケースを独立して実行 ● 結果的に「読みやすく・保守しやすい」テストに 

describe：関連するテストをまとめて構造化できる テストシナリオを構造化してグルーピングでき、 テストとのまとまりが分かりやすくなります 18 

beforeEach：各テスト前の共通処理を定義 他にもafterAllなど様々な定義があります。 19 

UI自動テストのAI活用は？ 20 

● ChatGPTやGitHub Copilotなどが登場し、コード生成が一般的に。 ● UIテストでも、AIがテストケースやシナリオを提案する動きが進む。 ● 「人がテストを設計し、AIが補助する」構図が現実的。 AIがテストを書く時代？ 21 

Playwright Agentsとは？（新機能） ● Playwright 1.56+ / VS Code 1.105+ で利用可能な最新AI機能 ● Microsoftが開発を進める「AIがテストを助ける仕組み」 ● Playwright内で動作する3種類のエージェントを搭載 ○ Planner：アプリを探索して、テスト計画を自動作成 ○ Generator：その計画からテストコードを生成 ○ Healer：テスト失敗時に原因を分析し、修正案を提示 ● これまでの「人が書く・直す」テストから、 ● AIが提案して人がレビューするスタイルへ進化 ● 現時点では実験的機能。今後のPlaywrightの方向性を示す重要なアップデート 22 

直近の事例 ● OpenStack(OSSのクラウド基盤ソフトウェア)環境の構築後、動作確認 ○ APIなどもあるが画面からユーザーが操作するテストを対象 ○ 主にインスタンスやストレージ、ネットワークが正しく表示、使用できるか ● 感想 ○ 画面から読み取れる情報のみで制御する必要があった ■ test-idなどを必要に応じて付与できない ○ 動的な部分は必要に応じて特定の要素が表示されるまで待つ制御は必要 ○ インフラ環境が立ち上がるまでの待ちを含めると実行時間は全体で30分くらい ■ GitHub Actions上で動かす場合にはクレジット消費量に注意 ○ 強引な実装や騙すようなことはせずに全体的に構築はできた印象 23 

おわり 24 

25