🎭

PlaywrightでQA作業を効率化した3つの方法

に公開

初めましてQA奥山です

AIによるコード自動生成やアジャイル開発の加速でQA作業がボトルネックとなっていませんか?
そんな課題を感じている方に向けてPlaywrightを活用した効率化の方法を3つ紹介します

(1) Figmaで作られた画面仕様書とコーディング実装されたWeb画面をPlaywrightで文言比較と画像比較する方法

目的

試験時の確認数(サイト数×ページ数×画面要素=1,000項目以上)が膨大となり、人による目視だとヒューマンエラーが発生する可能性が高い状況を取り除くため、Playwirhgtを使った文言比較と画面変化を検知するツールを実装する

内容

1. Figmaデザインを画像として切り取り、AIに画像から文字列を抽出させる

画像例

2. AIにて比較リスト(JSON)を生成する

画像例


3. JSON/list.jsonに2.の結果を貼り付ける

ディレクトリ構成例
FigmaCheck/
├─ JSON/
│  └─ list.json
├─ playwright/.auth/
│  └─ auth.json
├─ tests/
│  ├─ snapshots
│  │  └─ {url}.png
│  ├─ auth.setup.ts
│  └─ figmaCheck.spec.ts
└─ playwright.config.ts

4. Playwrightにて文字列比較と画像比較を実行する

コード処理の流れ

【文言比較(完全一致)】

  1. JSONファイルを元にForEachする
  2. JSONファイル内のURLキーを参考に対象画面を開く
  3. JSONファイル内のLISTキーを参考に画面内に対象の文言比較する

【画像比較(VRT)】

  1. JSONファイルを元にForEachする
  2. JSONファイル内のURLキーを参考に対象画面を開く
  3. 画面最下部まで下スクロール→最上部まで上スクロールすることで画面描画が安定する
  4. 画像比較する(fullPage: true, threshold: 0.0/完全一致)

結果

  • 文言比較の速度アップ
    • 自動化前:1画面あたり 約2分かかっていた
    • 自動化後:Playwright+AIで 約30秒に短縮
    • 差分:1画面あたり 約1分30秒の削減(約75%短縮)
  • JSON変更のみで使えるのでテスターにも使って貰えている

(2) テストシナリオ実行時に送られてくるメール本文をPlaywrightで文言比較する方法

目的

新規口座開設テストシナリオを例としてメールの種類がログイン通知、認証コード通知、口座開設申込の受付や完了、申込内容不備の修正依頼があり、またサイト毎の特徴がメール本文に反映されているかも含め、人による目視だとヒューマンエラーが発生する可能性が高い状況を取り除くため、Playwirhgtを使った文言比較するツールを実装する

内容

1. 比較元となるメール本文をコード化する

コード例
return new RegExp(
    '「口座開設のお知らせ」をお受け取りいただき、ありがとうございました。\\s+' +
    '「口座開設のお知らせ」のお受け取りが確認できましたので、次の手順で資産運用をスタートしてください。\\s+' +
    `・「${siteName}」へログイン\\s+` +
    '・リスク許容度診断を実施して、あなたにあったポートフォリオを決定\\s+' +
    '・最低投資額以上の入金\\s+' +
    '※ 資産運用を始めるには、リスク許容度の設定と最低投資額を超える入金が必要です。\\s+' +
    'おまかせNISAの口座開設をご希望の方は、以下よりお申し込みいただけます。\\s+' +
    `https://${sitePrefix}.wealthnavi.com/redirect/\\?url=/service/nisa/registration/router\\s+` +
    '何かご質問がありましたら、本メールにご返信ください。\\s+'
);

2. E2Eテストシナリオで送られてきたメール本文を1.の情報と比較する

コード例
await test.step('簡易書留のお受け取りありがとうございました メール確認', async (): Promise<void> => {
    const title = "簡易書留のお受け取りありがとうございました";
    const reg = await getAccountOpeningCompletedRegularExpression(name, code, prefix === 'invest' ? prefix : prefix + '.stg');
    await extractEmailBodyMatchesSearchCriteria(page, title, email, reg);
});

結果

  • メール本文比較の速度アップ
    • 自動化前:1通あたり 約1分かかっていた
    • 自動化後:Playwright+正規表現で 約15秒に短縮
    • 差分:1通あたり 約45秒の削減(約75%短縮)
  • wealthnavi.com/lp/055// のようにスラッシュが二重になっている本文の誤りも検知できました
  • 処理の共通化によってメール本文の考慮不足を検知

(3) テスト計画/設計からPlaywrightコード自動生成する方法

目的

テスト計画/設計からPlaywrightコードを自動生成することによって工数削減する

前提

  • 環境はVSCode、Playwright、GitHub Copilot(Agent/ClaudeSonnet4.5)を利用
  • GitHub Copilot カスタマイズ(copilot-instructions.md)

内容

1. GitHub Copilot(Agent)にテスト計画を依頼する

プロンプト例
対象: {screen} 画面
目的: テスト計画を plan/{screen}.md に保存
前提:
- 主要UI要素(ボタン、タブ、リンク、フォーム)を把握し、計画に反映
- タグ: 未連携は @unlink / 連携済は @link
- storageState 利用(@unlink = auth.json / @link = authLink.json)
観点: 正常系/異常系/UI/アクセシビリティ/リンク遷移/更新ボタン動作
出力: Markdown(概要 / 前提 / 観点 / テストケース一覧)
実行結果例

2. GitHub Copilot(Agent)にテスト設計を依頼する

プロンプト例
対象: plan/{screen}.md
目的: 実行可能なテスト設計仕様を作成し、design/{screen}.md に保存
形式: 表 (TC-ID | 前提 | 手順(番号) | 期待結果 | 備考)
要件:
- 各TCの前提/手順/期待結果を表形式で具体化
- ロケータ方針: getByRole / getByLabel を優先
- テストタイトルに @unlink / @link を付与(grepに合致)
実行結果例

3. GitHub Copilot(Agent)にテスト実装を依頼する

プロンプト例
対象: design/{screen}.md
目的: Playwright + TypeScript の POM 形式コードを生成
出力:
- pages/{screen}.ts
- tests/{screen}.spec.ts(@unlink / @link 付き)
要件:
- ロケータは getByRole/getByLabel を使用
- web-first assertions を優先(expect(locator).toBeVisible 等)
- playwright.config.ts の projects(unlink/link)と storageState を利用
実行結果例

4. テスト実行 + コードレビュー

生成されたテストコードをデバック実行しながらコードレビューする

プロンプト例
transactions.spec.tsとTransactionsPage.tsがPOMで繋がっていて、
2025年10月や10月1日〜10月31日など今月の日付となっていますが、
実行月となるように可変に変更できますか?
実行結果例

結果

  • テスト設計・実装・実行の速度アップ
    • 自動化前(手動テスト想定):設計〜実行 約60分/1画面あたり
    • 自動化後(GitHub Copilot+POM形式):設計〜実行 約20分/1画面あたり
    • 差分:約40分削減(約67%短縮)
  • 手動テスト手順もGherkin記法に変換してGitHub Copilotに引き渡すことで
    POM形式Playwrightテストコードを生成してくれる

まとめ

・文言比較と画像比較によってデグレ防止
・GitHubCopilotとPlaywrightを利用して工数削減

今後の課題としてE2Eテストは
テストが不安定で壊れやすい,実行時間が長い,テストの網羅性確保が難しい
などがあるかと思います

対策としてPlaywrightがAPIテストも実施できるので
最低限のE2Eテスト網羅的なAPIテスト
で対処しようと考えています

長文となりましたが読んでくださりありがとうございました
読んでくださっている皆様にとってより良い品質作りの参考になれば幸いです

WealthNavi Engineering Blog

Discussion